Сотрудник 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 – порешалось переустановкой? Нет…

В этой версии исправлено:

• Проблема с десериализацией данных в системах с ВМ, требующими консолидации.
• Несоответствие имен папок устройств vCLS в отчетах.
• Проблема с несоответствием имен папок Placeholder-ВМ в Site Recovery Manager.
• Проблема с аварийным завершением работы RVTools в системах с включенным FIPS.
• Проблема с преобразованием числовых строковых значений в научную нотацию в Excel.
• Проблема с периодическими ошибками при расшифровке паролей.

Обновлено:

• Обновлено решение RVTools для использования VMware vSphere Management SDK 8u3.
• Обновлен целевой .Net Framework до версии 4.7.2

В этой версии исправлено:

• Проблема, требующая, чтобы рабочий каталог был установлен в каталог установки RVTools при использовании сценариев командной строки.
• Проблема, возникающая, когда при копировании/вставке имени хоста или имени пользователя включался ведущий или завершающий пробел.
• Проблема, при которой фоновые ошибки не позволяли успешно завершить работу RVTools в неинтерактивном режиме в качестве запланированного задания.
• Протоколирование ошибок теперь включено по умолчанию для ускорения поиска неисправностей. Ручное переключение на уровень отладки теперь будет запрашиваться только в ситуациях, требующих более подробной информации об устранении неполадок. ПРИМЕЧАНИЕ: Расположение файлов журнала по умолчанию было перенесено в папку AppData/Local/RVTools пользователя.
• Устранена проблема с повреждением csv-файлов при использовании значений, содержащих двойные кавычки.

Добавлено:

• Дополнительная программа улучшения продукта для сбора минимальных анонимных телеметрических данных для использования в целях оптимизации пользовательского интерфейса и эффективности RVTools. Дополнительную информацию смотрите на странице “О RVTools”. *При установке можно отказаться.
• На странице вкладки vHost появились новые столбцы: Compliance Check State, Domain List, Memory Tiering Type.
• На странице вкладки vHost появились новые столбцы Certificate: Certificate Issuer, Certificate Start, Certificate Expiry, Certificate Status, Certificate Subject.
• На странице вкладки vInfo новые столбцы: Suspended To Memory, Suspend Interval.
• На странице vInfo новые столбцы: Overall Cpu Readiness, Active Memory, Fixed Passthru Hot Plug, Op Notification Timeout, VM Failover In Progress.
• На странице вкладки vInfo новый столбец Customization Info.
• На странице vInfo новый столбец Guest Detailed Data, который включает – architecture, bitness, buildNumber, cpeString, distroName, distroVersion, familyName, kernelVersion, prettyName.
• На странице вкладки vHealth: Добавлено предупреждение “Срок действия сертификата истекает через XX дней или уже истек” (настраиваемые XX дней).
• Свойства Health: Новый флажок для включения/выключения предупреждения об истечении срока действия сертификата и настройки желаемых временных рамок (по умолчанию = 90 дней).

1. Перестал работать DRS по причине невозможности создать виртуальные машины vCLS.
2. Перестало работать обновление хостов с ошибкой “Failed to login to vCenter as extension, Cannot complete login due to an incorrect user name or password”.

Изучение БЗ VMware навело на две заметки:

1. EAM is unable to deploy vCLS VMs when vpxd-extension certificate has incorrect extended key usage values (85742)
2. “Failed to login to vCenter as extension, Cannot complete login due to an incorrect user name or password”, ESX Agent Manager (com.vmware.vim.eam) solution user fails to log in after replacing the vCenter Server certificates in vCenter Server 6.x/7.x (2112577)

Что-то подсказывало, что корень у причины один!

Подали советуемые команды, которые починили сертификат расширения:

mkdir /certificate
 /usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.crt
 /usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store vpxd-extension --alias vpxd-extension --output /certificate/vpxd-extension.key
 python /usr/lib/vmware-vpx/scripts/updateExtensionCertInVC.py -e com.vmware.vim.eam -c /certificate/vpxd-extension.crt -k /certificate/vpxd-extension.key -s vcenter-name.loc -u Administrator@vsphere.local
 service-control --stop vmware-eam
 service-control --start vmware-eam

При разборе полётов было выяснено, что в Emulex Drivers for ESXi 7.0 с релиза 14.0.326.12 прекращена поддержка адаптеров LPe12000-series, LPe15000-series и LPe16000-series.

Соответственно, последними версиями с поддержкой данных адаптеров являются lpfc 14.0.169.25-5vmw и lpfc 12.8.614.16.

После понижения драйверов адаптеры появились.