09.03.21 г. вышел релиз ESXi 7.0U2, и его первоначальное тестирование показало ряд разной степени критичности ошибок и сопутствующих проблем. Ниже мы их распишем во всех подробностях, а также, по возможности, приведем методы устранения, для удобства разбив всю проблематику по категориям воздействия.
Проблемы с сетью
- Issue: Паравиртуальные сетевые адаптеры RDMA (PVRDMA) не поддерживают сетевые политики NSX. Если настроить распределенный виртуальный порт NSX для использования трафика PVRDMA, трафик протокола RDMA через сетевые адаптеры PVRDMA несовместим с сетевыми политиками NSX.
Resolve: Не настраивать распределенный виртуальный порт NSX для использования трафика PVRDMA.
- Issue: Сетевые адаптеры Solarflare x2542 и x2541, настроенные в режиме порта 1x100G, достигают пропускной способности до 70 Гбит/с в среде vSphere. Несмотря на то, что vSphere 7.0U2 поддерживает такие сетевые адаптеры, можно наблюдать ограничение по «железу» в устройствах.
Resolve: нет.
- Issue: После перезагрузки NIC трафик VLAN может упасть. NIC с PCI идентификатором устройства 8086:1537 может перестать посылать и получать тэггированные VLAN пакеты после перезагрузки, например, с командой: «vsish -e set /net/pNics/vmnic0/reset 1»
Resolve: Избегать перезагрузки NIC. Если же проблема все-таки случилась, использовать для восстановления возможностей VLAN команды (пример для vmnic0):
# esxcli network nic software set –tagging=1 -n vmnic0
# esxcli network nic software set –tagging=0 -n vmnic0
- Issue: Любое изменение в параметрах NetQueue балансера с помощью команды:
esxcli/localcli network nic queue loadbalancer set -n <nicname> –<lb_setting>
ведет к выключению NetQueue после перезагрузки ESXi-хоста.
Resolve: После всего проделанного использовать команду:
configstorecli config current get -c esx -g network -k nics
для получения данных ConfigStore для подтверждения, работает ли «/esx/network/nics/net_queue/load_balancer/enable» как ожидается. Вывод должен быть примерно таким:
{
“mac”: “02:00:0e:6d:14:3e”,
“name”: “vmnic1”,
“net_queue”: {
“load_balancer”: {
“dynamic_pool”: true,
“enable”: true
}
},
“virtual_mac”: “00:50:56:5a:21:11”
}
Если же в нем встречается, например, «load_balancer”: “enable”: false», запустить следующее:
esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true
- Issue: Задержка чтения адаптеров QLogic 16Gb Fibre Channel, поддерживаемых драйвером qlnativefc, растет при некоторых условиях. Если ВМ зашифрована, задержка последовательного чтения увеличивается на 8% в ESXi 7.0 Update 2 по сравнению с тем, что было актуально для ESXi 7.0 Update 1. Для незашифрованных машин она растет на 15-23%.
Resolve: нет.
Безопасность
- Issue: Выключение службы Service Location Protocol на ESXi (slpd) для предотвращения потенциальных пробоев в безопасности. Некоторые службы ESXi, работающие поверх операционной системы хоста, включая slpd, брокер объектов CIM, sfcbd и родственные openwsmand службы, доказали свою уязвимость в плане безопасности. Все подобные выявляемые уязвимости адресуются в VMSA-2019-0022 и VMSA-2020-0023 и, по мере возможностей, VMware старается их исправлять. Однако, если sfcbd и openwsmand по дефолту на ESXi выключены, slpd, напротив, включена, и, если в ней нет необходимости, рекомендуется ее выключить, чтобы предотвратить возможные будущие уязвимости после апгрейдов.
Resolve: Чтобы выключить службу slpd, использовать команды:
$ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Set-VMHostService -policy “off”
$ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Stop-VMHostService -Confirm:$false
Альтернативно, можно запустить: «chkconfig slpd off && /etc/init.d/slpd stop».
Стоит отметить, что служба openwsmand не представлена в списке служб ESXi, но, проверить ее статус можно командами:
$esx=(Get-EsxCli -vmhost xx.xx.xx.xx -v2)
$esx.system.process.list.invoke() | where CommandLine -like ‘*openwsman*’ | select commandline
А служба sfcbd там есть, но представлена как «sfcbd-watchdog». Больше информации по этой теме можно получить из этого и этого КБ.
Разные проблемы
- Issue: Не получается снять снэпшот ВМ из-за ошибки о сбое в операции дайджеста. Изредка, плавающее условие, при котором состояние All-Paths-Down (APD) появляется в процессе обновления файла дайджеста Content Based Read Cache (CBRC), может привести к несоответствию в дайджесте файла. Из-за этого нельзя снять снэпшот машин и видна ошибка:
An error occurred while saving the snapshot: A digest operation has failed
Resolve: Запустить цикл включения ВМ для вызова повторного вычисления хэшей CBRC и очистки несоответствий в файле дайджеста.
- Issue: ESXi-хост падает в фиолетовый диагностический экран из-за редкого условия в драйвере qedentv. Проблема появляется, когда полное прерывание Rx случается сразу после уничтожения пары очередей (QP) General Services Interface (GSI). Например, во время выгрузки драйвера qedentv или завершения работы системы. В таком случае этот драйвер не может получить доступ к уже освободившемуся адресу QP, в результате чего PF исключается. Известно для хостов ESXi, подключенных к занятому физическому свитчу с интенсивным не запрошенным трафиком GSI. В трассировке будут сообщения:
cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
#PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1c
Resolve: нет.
Проблемы хранилища
- Issue: Если NVMe-устройство добавлено и удалено на горячую практически подряд, ESXi-хост падает в фиолетовый диагностический экран. Драйвер NVMe не может инициализировать NVMe-контроллер из-за времени истечения команды. В результате драйвер может попробовать достучаться до памяти, которая уже освобождается в процессе очистки. В трассировке будет значиться:
WARNING: NVMEDEV: NVMEInitializeController:4045: Failed to get controller identify data, status: Timeout.
Случается, что в этом случае хост падает в фиолет с ошибкой, вида:
#PF Exception … in world …:vmkdevmgr
Resolve: Выполнять операции замены на горячую исключительно после завершения предыдущей операции. Например, если нужно запустить удаление после добавления, следует дождаться создания HBA и обнаружения LUN. Для альтернативного сценария (добавление после удаления) важно дождаться, пока все LUN и HBA не будут удалены.
Проблемы с управлением ВМ
- Issue: UEFI HTTP-загрузка ВМ на хостах версий, древнее 7.0U2, может дать сбой.
Resolve: Использовать UEFI HTTP-загрузку только для ВМ с «железом» версии 19 или свежее. При этом хосты должны иметь ESXi 7.0U2 или более новые.
Проблемы с vSAN
- Issue: Если поменять предпочтительный сайт в растянутом кластере vSAN, некоторые объекты могут некорректно отображаться как соответствующие. Это происходит потому, что параметры политики таких объектов могут не меняться автоматически. Например, если настроить ВМ на хранение данных на предпочитаемом сайте, при смене этого сайта на другой, данные могут остаться на не предпочитаемом.
Resolve: Перед сменой предпочитаемого сайта в Advanced Settings, уменьшить параметр «ClomMaxCrawlCycleMinutes» до 15 минут, чтобы политики объектов успели проапдейтиться. После изменения восстановить эту опцию до прежнего значения.
Проблемы с инсталляцией, апгрейдом и миграцией
- Issue: UEFI-загрузка ESXi-хостов может остановиться с ошибкой при апдейте до ESXi 7.0U2 с более ранних версий «семерки». Ошибка вида:
Loading /boot.cfg
Failed to load crypto64.efi
Fatal error: 15 (Not found)
Resolve: Использовать baseline обновления хостов после импорта образа актуальной версии в инвентарь vCenter Server, если его еще нет в хранилище vLCM. Больше информации в КБ.
- Issue: Если старые VIB все еще используются на ESXi-хосте, vLCM не может извлечь желаемую спецификацию софта в сид нового кластера. В vCenter Server 7.0U2 можно создавать новые кластера импортированием спецификации софта из единственного эталонного хоста. Но, если старые VIB все еще в деле, в «/var/log/lifecycle.log» можно получить сообщение вида:
020-11-11T06:54:03Z lifecycle: 1000082644: HostSeeding:499 ERROR Extract depot failed: Checksum doesn’t match. Calculated 5b404e28e83b1387841bb417da93c8c796ef2497c8af0f79583fd54e789d8826, expected: 0947542e30b794c721e21fb595f1851b247711d0619c55489a6a8cae6675e796 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:366 ERROR Extract depot failed. 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:145 ERROR [VibChecksumError]
Resolve: Воспользоваться рекомендациями из КБ.
- Issue: Может наблюдаться краткое наращивание активности сообщений в syslog.log после каждой загрузки ESXi, например, показывается такое:
2021-01-19T22:44:22Z watchdog-vaai-nasd: ‘/usr/lib/vmware/nfs/bin/vaai-nasd -f’ exited after 0 seconds (quick failure 127) 1
2021-01-19T22:44:22Z watchdog-vaai-nasd: Executing ‘/usr/lib/vmware/nfs/bin/vaai-nasd -f’
2021-01-19T22:44:22.990Z aainasd[1000051135]: Log for VAAI-NAS Daemon for NFS version=1.0 build=build-00000 option=DEBUG
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoadFile: No entries loaded by dictionary.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file “/usr/lib/vmware/config”: No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file “//.vmware/config”: No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file “//.vmware/preferences”: No such file or directory.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: Switching to VMware syslog extensions
2021-01-19T22:44:22.992Z vaainasd[1000051135]: Loading VAAI-NAS plugin(s).
2021-01-19T22:44:22.992Z vaainasd[1000051135]: DISKLIB-PLUGIN : Not loading plugin /usr/lib/vmware/nas_plugins/lib64: Not a shared library.
Resolve: Смысловой нагрузки не несет. Можно игнорировать.
- Issue: Показываются предупреждения о пропущенных VIB в отчетах проверки совместимости vSphere Quick Boot после обновления до последней версии гипервизора и использования команды «/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py», вида:
Cannot find VIB(s) … in the given VIB collection.
Ignoring missing reserved VIB(s) …, they are removed from reserved VIB IDs.
Resolve: Можно спокойно не обращать внимания. Проблему совместимости не отражают. Конечная строка вывода команды «loadESXCheckCompat» покажет совместимость хоста.
- Issue: Автоматическая загрузка кластера, управляемого с помощью образа vSphere Lifecycle Manager, завершается ошибкой:
2021-02-11T19:37:43Z Host Profiles[265671 opID=MainThread]: ERROR: EngineModule::ApplyHostConfig. Exception: [Errno 30] Read-only file system
Resolve: Следовать гайдам вендора по очистке VMFS-партиций на целевом хосте и повторить операцию. Альтернативно использовать чистый диск. Больше узнать об этом поможет КБ.
Если по перечисленным проблемам без решения появятся какие-то дельные пути их устранения, а также, если обнаружатся дополнительные, связанные с новой версией гипервизора, ошибки, эта статья непременно будет соответствующим образом дополнена.