Сотрудник VMware выпустил сетевой драйвер для чипов Realtek для ESXi 8 и 9:

• RTL8111 – 1GbE
• RTL8125 – 2.5GbE
• RTL8126 – 5GbE
• RTL8127 – 10GbE

Данную весть опубликовал William Lam в заметке Realtek Network Driver for ESXi.

На простой вопрос ведь есть простой ответ – посмотреть HCL!

Открываю HCL, смотрю Supported Virtual Hardware Versions: 15,17,18,19,20,21,22.

Всё! Расходимся! Или кто-то недоговаривает?

Начинаю вспоминать, что под 7-ой были какие-то заморочки с выбором ОСи при создании ВМ-ки с MS WS 2022 – Windows Server 2022 guest operating system option is not available during virtual machine creation.

После перехода на 8-ку стали прорабатывать вопрос перехода на NVMe End2End. Открываем историю функционала vHW на virten.net, а там написано, что лучше бы на 21-ую версию глянуть для NVMe 1.3  – Virtual Machine Hardware Versions. А на сам Windows Server надо патч KB5029250 накатить –
Hot add/remove disk on vNVMe controller doesn’t work properly with Window guest OS.

Другие известные косяки с MS WS 2022 (выбрал самые интересные):

• Update of VMware tools 12.5.1 on a Windows 2022 Server, domain network connectivity issue is seen
• Windows Server 2022 Virtual Machine Loses Network Connectivity When Using E1000E Adapter
• Guest OS in-place upgrade to Windows Server 2022 or Windows 11 failed after upgrading VMware Tools to 12.0.5 or later on vSphere
• Application-Consistent Quiescing snapshot is not enabled by default for Windows Server 2022
• Unable to enable Fault Tolerance on a Windows Server 2022 or 2025 VM when VBS is enabled
• Customers implementing MS November 2024 patches causes VCSA (and potentially other products) to fail authentication
• Virtual Machines on AMD platforms with Windows Guest OS encounter BSOD after enabling Virtualization-Based Security (VBS)

Так что могут рекомендовать для 7-ки использовать для Windows Server 2022 vHW 18+ на Intel, vHW 19 на AMD c VBS, для 8-ки с NVMe vHW 21.

95% нагрузок перемещаются без каких-либо последствий, но 5% могут иметь занимательные проблемы – я бы назвал это похмельным синдромом перемещения.

В чём он выражается? Во время миграции вы ощущаете лёгкое отупление как от употребления алкоголя в чуть повышенной дозе, а потом жесточайшие тормоза, длящиеся от пары до пары десятков минут.

vMotion имеет длительную историю, но для меня ключевыми вехами стали версии 5 и 7 (новый функционал релизнули в 7u1). Например, в 5-ке появился целый набор технологий – Mirror [Copy] Driver, Stun During Page Send и Multi-NIC vMotion.

Лучшее доступное описание по архитектуре и настройке читайте в блоге Frank Denneman:

Part 1 – Designing your vMotion network
Part 2 – Multi-NIC vMotion failover order configuration
Part 3 – Multi-NIC vMotion and NetIOC
Part 4 – Choose link aggregation over Multi-NIC vMotion?
Part 5 – 3 reasons why I use a distributed switch for vMotion networks

В 7-ке разработчики озадачились миграцией виртуальных машин с большой нагрузкой и выкатили Monster VM vMotion, о чём подробно можно почитать в документе:

vMotion Innovations in VMware vSphere7.0 U1 .

Теперь вернёмся к причине похмельного синдрома после перемещения – приведу короткую цитату из Sensitive Virtual Machines become impacted by vMotion stun time:

some highly sensitive applications like Database or Banking applications have been known to encounter crash’s or persistent performance impact due to the stun or suspend resume time they experienced as part of the vMotion.

Что же вредного делает этот stun? А он при перемещении ВМ понижает частоту виртуальных процессоров до уровня, когда миграция начинает успевать передавать изменённые страницы памяти с хоста на хост и чем интенсивнее приложение меняет содержимое памяти, тем сильнее приходится прижимать ресурсы процессора. В итоге, мы видим резкий рост очередей на процессор. Пример проблемы на графике: на 20 процессоров две очереди во время миграции составляют по 600 сессий, а потом ~15 минут в районе 300 сессий из-за накопительного эффекта + наложилась борьба за 101% памяти на хосте.

Как сократить время миграции и нивелировать действия stun? Я выбрал старый метод – расширить канал с использованием Multi-NIC vMotion!

У меня есть два сегмента с проблемной миграцией – обычные машины плохо едут по 1 Гбит/с, тяжёлые машины плохо едут по 10 Гбит/с.

Открываем вышеуказанные ссылки плюс статью Multiple-NIC vMotion in vSphere и настраиваем отдельные VMkernel-интерфейсы с сетевыми картами в режиме Active-Standby первый, в режиме Standby-Active второй в политике Teaming and Failover.

У меня ситуация с 10-ками получилась не очень – сетевухи уже 25 Гбит/с, а свитчи всё ещё 10 Гбит/с. Но тяжелые ВМ-ки у меня в 2-узловом кластере, соответственно, интерфейсы под vMotion переключаем на DAC и получаем 2 по 25 Гбит/с.

Результаты

Примечание. Тюнинг vMotion не использовался. Конфигурация железа разная в vSphere 6.7 и в 8.0.

Переход с 6.7 на 7.0 – один канал vMotion на 10 Гбит/с, проверяем улучшения в 7-ке. Миграция ВМ с работающей под высокой нагрузкой системой управления базами данных Oracle DB (20 виртуальных процессоров и 242 гигабайта оперативной памяти) была перемещена за 3 минуты 47 секунд по сравнению с 4 минутами 8 секундами в версии 6.7 – ускорение составило порядка 10%.

Меняем 7-ку на 8-ку, постепенно изменяем конфигурацию сети vMotion:

ВМ СУБД Oracle DB, низкая нагрузка (64 ГБ, 4 vCPU)
Скорость сети, Гбит/с	Время миграции, сек	Пиковая скорость
10	51	1,2 ГБ/с
25	23	1,8 ГБ/с
2*25	14	2,7 ГБ/с
ВМ СУБД Oracle DB, низкая нагрузка (320 ГБ, 20 vCPU)
Скорость сети, Гбит/с	Время миграции, сек	Пиковая скорость
2*25	76	5,3ГБ/с
ВМ СУБД Oracle DB, высокая нагрузка (320 ГБ, 20 vCPU)
Скорость сети, Гбит/с	Время миграции, сек	Пиковая скорость
10	~51 минута	~1,2 ГБ/с
2*25	61	6,2 ГБ/с

В результате тестов стало ясно, что скорость vMotion растёт практически линейно, если есть что перемещать, – мы получили ускорение до 5 раз при переходе с 10 на 2*25. Для не слишком тяжёлых виртуальных машин не хватает разгона, так как основное время занимают сервисные операции. Если широкого канала хватает для покрытия скорости изменения памяти, то stun не используется и не влияет на время миграции, также мы не видим каких-то особо выраженных пиков по очередям процессора во время начала и конца миграции, да и похмелья у ВМ-ки нет.

Обновление vCenter встаёт по таймауту

Обновили несколько vCenter’ов и на очередном обновлятор встаёт колом:

При этом даёт классный совет, типа, за 1 час не успеваю, дай мне побольше времени:
Upgrade phase timed out. The time planned for the upgrade phase
was 60 minutes. The upgrade phase has already been running for 60
minutes. To extend the default timeout, set environment variable
UPGRADE_EXPORT_TIMEOUT
Поиск дал ссылочку на БЗ –  The vCenter Server upgrade from version 7.0 to 8.0 fails at 39% with the error: “Upgrade phase timed out” after getting stuck during the “Exporting the VMware Analytics Service data” step
Запускаем предложенный скрипт и смотрим на наличие 127k файликов в аналитике:

root@vc [ /tmp ]# ls /var/log/vmware/analytics/prod | wc -l
127465
root@vc [ /tmp ]# chmod +x cleaning_vddk_script.sh
root@vc [ /tmp ]# ./cleaning_vddk_script.sh 90
Files before the clean :
127452 ===
Start cleaning VDDK files older than 90 days...
Clean successful! ===
Files after the clean:
0
root@vc [ /tmp ]# ls /var/log/vmware/analytics/prod | wc -l
102

Зачем сломали интерфейс?

Интерфейс в 7-ке были вылизан и привычен. В 8-ке решили, что FULL HD мониторы – это прошлый век, и исправили иконки, всплывающие длинные поля поменяли на полный вывод, а если название хоста не влезет, то не постеснялись в 2 этажа отобразить. Выбор нескольких строк тоже поломали.

Старое оборудование не поддерживается в ESXi 8

После эпопеи VMware ESXi 7.0 и неподдерживаемое оборудование отказ от оборудования в 8-ке продолжился. По процессорам у нас вышли из поддержки Intel Xeon 26xx v2 – хорошо, отправим на списание. Для любителей хлама – неофициально ESXi8 на старых процессорах работает Heads Up – ESXi 8.0 Update 2 requires XSAVE CPU instruction even with allowLegacyCPU=true.
Актуальной остаётся проблема Отвал FC HBA Emulex 8/16-Gb/s после обновления VMware ESXi 7.0 update 3. Драйвер нужно интегрировать старый.

Загрузка ESXi и TPM 2.0

8-ка стала требовать включения TPM 2.0 на серверах (с TPM 1.2 грузится, но ругается):
TPM 1.2 device detected. Support for TPM version 1.2 is discontinued. Installation may proceed, but may cause the system to behave unexpectedly.Make sure the host is upgraded to TPM 2.0.
Как оказалось, на всех старых серверах необходимо на уровне UEFI, а местами и джамперов, переключаться на TPM 2.0.
Как включить TPM 2.0 на серверах Lenovo:

• How to set TPM and enable secure boot on a Lenovo ThinkSystem
• 3550 M5 System-board switches, jumpers, and buttons
• 3650 M5 TPM 2.0

QuickBoot и TPM 2.0, а ещё TXT и IPMI

С 8-ки поддерживается QuickBoot на серверах с TPM 2.0, но встаём на целый набор граблей: современный сервер пишет, что поддержки нет. Запускаем утилиту проверки для определения причин:

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
BmcInfo: ipmi returned invalid data length: 1 ccode 255
BmcInfoImpl: Retrieve Version information failed
This system is not QuickBoot compatible: violating one or more strict requirements (Quick Boot is not supported on this machine)
The host does not fulfill the following hard dependencies:
- Intel TXT is enabled

Ищем где выключить TXT на серверах Lenovo  – находим нужный пункт в этой КБ:

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
BmcInfo: ipmi returned invalid data length: 1 ccode 255
BmcInfoImpl: Retrieve Version information failed
This system is compatible with Quick Boot.

По второй ошибке – “BMC Firmware Version” missing in System information of VMware DCUI, проверяем, что поля заполнены или нет:

esxcli hardware ipmi bmc get
BMCFirmware Version: 0.00
Hostname Reported:
IPMIVersion: 0.0
IPv4Address:
IPv4Gateway:
IPv4Subnet:
IPv6Addresses:
LANif Admin Status: false
MACAddress:
Manufacturer: Unknown
OSName Reported:

Ошибка спустя несколько минут исправилась после перезагрузки контроллера.
В итоге получаем:

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
This system is compatible with Quick Boot.

Проблема с плагином Veeam BR

Также отвалился плагин для Veeam BR – порешалось переустановкой? Нет…

• Дорожная карта SpaceVM.
• Дорожная карта SpaceVDI.

Состав стенда:

1. Два набора оборудования:
   • СХД Аэродиск;
   • сервер виртуализации Aquarius;
   • коммутатор Qtech.
2. Один набор ПО:
   • СУБД Postgres Pro под синтетической нагрузкой;
   • платформа анализа данных Visiology с рабочим местом администратора и руководителя ИТ-инфраструктуры и панелью по анализу данных;
   • система виртуализации zVirt;
   • система мониторинга Пульт.

*Между двумя площадками эмулируется расстояние 60 км.

Смотреть видеозапись.

Запись эфира AM Live.

• Дорожная карта SpaceVM.
• Дорожная карта SpaceVDI.

Запись мероприятия.

• Виртуализация на отечественном: как дела сегодня и что нас ждет завтра?
• Дискуссия: Виртуализация на отечественном. Опыт выбора и применения решений на практике
• Геораспределенная защита виртуальной инфры от катастроф, отказов и атак. Платформа, ЦОД или облако — теперь не важно
• Инфраструктурное ПО в ЦОД. Русификация мировых трендов, региональная специфика или работа на опережение
• Неочевидные особенности внедрений СРК, и как с ними работать