Категорії
News 2020

VMware ESXi 7.0U1c Release Notes

17 декабря 2020 года VMware выпустила патч к ESXi 7.0U1. Изменился актуальный билд гипервизора и многие другие интересные вещи, в частности, касающиеся поддержки серверов, а также был исправлен внушительный список ошибок, сопровождавших нас багажом с предыдущих релизов.

О первом серьезном апдейте – ESXi 7.0U1 мы писали здесь. А о предыдущих двух патчах (7.0U1a и 7.0U1b) – можно почитать в этой статье.

Актуальная сборка

Билд 17325551 ESXi 7.0U1c доступен для скачивания по этой ссылке:

Изменения в патче 7.0U1c

  • Поддержка vSphere Quick Boot на следующих серверах:
    • Cisco Systems Inc:
      • HX240C-M5SD
      • HXAF240C-M5SD
      • UCSC-C240-M5SD
    • Dell Inc:
      • PowerEdge C6420
      • PowerEdge C6525
      • PowerEdge FC640
      • PowerEdge M640
      • PowerEdge MX740c
      • PowerEdge MX840c
      • PowerEdge R540
      • PowerEdge R6515
      • PowerEdge R6525
      • PowerEdge R7515
      • PowerEdge R7525
      • PowerEdge R840
      • PowerEdge R930
      • PowerEdge R940
      • PowerEdge R940xa
    • HPE:
      • ProLiant DL385 Gen10
  • С целью изменения максимальной длины сообщений журнала логов теперь можно использовать параметр «–remote-host-max-msg-len», что позволяет достичь 16 KiB до момента, когда придется их разделить;
  • Стало доступно применение опции загрузчика инсталляции «systemMediaSize» для ограничения партиций системного хранилища на загрузочных медиа. Принимаются следующие значения:
    • min (33 ГБ, для единственного диска или встроенных серверов),
    • small (69 ГБ, для серверов с, по крайней мере, 512 ГБ RAM),
    • default (138 ГБ),
    • max (съедает все доступное пространство – для мульти-терабайтных серверов).

Апдейты VIB и драйверов

Список VIB в патче 7.0U1c:

Loadesx,

esx-update,

vmkata,

nhpsa (проапдейчен nhpsa-драйвер),

vmkusb,

smartpqi (проапдейчен smartpqi-драйвер),

esx-dvfilter-generic-fastpath, vsanhealth, vdfs, vsan, esx-base, crx, native-misc-drivers, esx-xserver, gc и cpu-microcode (проапдейчены SQLite база данных, библиотека OpenSSL, OpenSSH, демон NTP, библиотека libcurl),

nvmerdma,

vmkfcoe.

Исправленные в апдейте 7.0U1c ошибки

  • Может наблюдаться потеря сетевого подключения в результате физической перезагрузки свитча. Параметр «TeamPolicyUpDelay» для задержки восстановления после сбоя сетевого тиминга на ESXi-хостах в настоящее время установлен на значении в 10 минут, однако в некоторых средах физический коммутатор может потребовать больше для перехода в состояние готовности к приему или передаче данных после ребута. В результате сетевое подключение теряется.
  • Изменение в конфигурации фильтра DFW может вынудить ВМ потерять сетевое подключение. Любое добавление или удаление фильтров вызывает начало потери пакетов. В результате ВМ теряет сетевое подключение и нужно перезагрузить vmnic, изменить порт-группу или перезагрузить саму ВМ для восстановления трафика. Статус засбоившего фильтра при выводе команды «summarize-dvfilter»:

state: IOChain Detaching

  • ВМ может упасть с ошибкой «SIGSEGV» в процессе 3D-рендеринга. Повторное обращение к буферу во время некоторых операций рендеринга может привести к сбою ВМ с поддержкой 3D и выдаст ошибку при взаимодействии с граф-приложениями, использующими 3D-ускорение.
  • ВМ перезагружается или перезапускается в процессе операций горячего подключения, логи в «vmware.log» могут перезаполнить собой все свободное дисковое пространство и машина попросту перестанет отвечать. Сообщения логов идентичны, например:

acpiNotifyQueue: Spurious ACPI event completion, data 0xFFFFFFFF

  • smpboot падает на Linux-ВМ с включенным статусом Secure Encrypted Virtualization-Encrypted State (SEV-ES). Происходит на машинах со множеством vCPU и при этом все CPU, включая CPU0, уходят в оффлайн. Обратно вернуть их не получается. Команда «dmesg» возвращает ошибку вида:

smpboot: do_boot_cpu failed(-1) to wakeup CPU#1

  • Если в директории ВМ есть своп-файлы «.vswp», появляется ошибка занятости ресурсов или устройств («Device or resource busy») при сканировании всех файлов в директории. Также наблюдается экстра-поток операций ввода-вывода на vSAN namespace-объектах, а сервис hostd замедляется. Проблема появляется, когда идет попытка открыть файл с таким расширением как дескриптор объекта.
  • Сервис hostd периодически перестает отвечать. В редких случаях, состояние соперничества множества потоков, пытающихся создать файл и удалить директорию в одной и той же директории, может вызвать полный локдаун, который уронит hostd-сервис. Сервис восстанавливается только после перезапуска ESXi-хоста. В логах vmkernel появляются предупреждения:

2020-03-31T05:20:00.509Z cpu12:4528223)ALERT: hostd detected to be non-responsive

  • Шифрование ВМ идет слишком долго (несколько часов) и в конечном итоге выдает ошибку:

The file already exists

в логах сервиса hostd. Проблема возникает, когда осиротевший или неиспользуемый файл «<vm name=””>.nvram» существует в файлах конфигурации ВМ. Если у ВМ в «.vmx»-файле есть строка вроде «NVRAM = “nvram”», операции шифрования создают зашифрованный файл с расширением «.nvram», которые система рассматривает как дубликат уже имеющегося осиротевшего файла.

  • Хост vSAN падает в процессе отключения большого клиентского кэша (256 ГБ или больше). ESXi-хост уходит в фиолетовый экран.
  • При включении LiveCoreDump как опции для сбора системных логов на ESXi-хосте, хост перестает отвечать. Ошибка на фиолетовом диагностическом экране вида:

#PF Exception 14 in world 2125468

  • После апгрейда «железа» HPE Gen10 серверов появляются health-предупреждения для датчика ID 44. Это случается для второго модуля ввода-вывода «ALOM_Link_P2» и сенсора «NIC_Link_02P2», относящихся к ID 44.x.
  • При отключении RC4 пользовательская аутентификация AD на ESXi-хостах может сбоить. Ошибка вида:

Failed to authenticate user

  • ВМ на NFS1 дата-сторадже могут перестать отвечать после аварийного восстановления или отката NFS-сервера.
  • Время, которое процессор проводит в системном режиме (%SYS), увеличивается для определенных рабочих процессов дискового ввода-вывода на ВМ.
  • Java-приложения на AMD-хостах в Enhanced vMotion Compatibility (EVC)-кластере могут перестать запускаться с ошибкой о не поддерживаемости SSE2:

Unknown x64 processor: SSE2 not supported

Происходит из-за некорректного значения поля CPUID «family (leaf 1, EAX, bits 11-8)».

  • После апгрейда HPE-серверов до HPE Integrated Lights-Out 5 (iLO 5) версии «железа» 2.30 выдаются предупреждения о здоровье сенсора.
  • Если SD-карта не поддерживает Read Capacity 16, в логах vmkernel появляется невероятное количество ошибок вида:

2020-06-30T13:26:06.141Z cpu0:2097243)ScsiDeviceIO: 3449: Cmd(0x459ac1350600) 0x9e, CmdSN 0x2452e from world 0 to dev “mpx.vmhba32:C0:T0:L0” failed H:0x7 D:0x0 P:0x0 Invalid sense data: 0x0 0x6e 0x73.

и

2020-06-30T14:23:18.280Z cpu0:2097243)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device “mpx.vmhba32:C0:T0:L0” state in doubt; requested fast path state update…

  • В случае не-UTF8-строки в свойстве имени числовых сенсоров, сервис vpxa падает.
  • Managed Object Browse может показывать статус сенсоров CPU и памяти некорректно. Из-за ошибок в обработки записей сенсоров, данные «memoryStatusInfo» и «cpuStatusInfo» могут неправильно включать статус для сенсоров, не относящихся к CPU и памяти.
  • Инсталляция ESXi сбоится на медиа с не отформатированными или поврежденными хранилищами данных. Повреждение VMFS-партиции, не отформатированность или другой владелец системы.
  • Записи аудита, сконфигурированные для рабочего раздела, теряются при обновлении до ESXi 7.x с 6.7 U2 и позднее.
  • После бэкапа сообщения ошибки идентичности выдаются потоком в файл «log» вида:

Block list: Cannot convert disk path <vmdk file> to real path, skipping.

  • Алгоритм vSphere Virtual Volumes может не подбирать первый Config-VVol, который требует ответа от ESXi-хоста. Известно для НА-сред.
  • В клиенте vSphere нельзя поменять уровень конфигурации журнала логов vpxa-сервиса после апгрейда системы vCenter Server. Для API то же самое.
  • ESXi на USB или FCoE-устройствах не может найти пути загрузчика устройства. Известно для медленных загрузочных устройств.
  • Агент VMware vSphere High Availability может перестать отвечать из-за проблем с памятью. Происходит под управлением образами vSphere Lifecycle Manager. Ошибка вида:

The vSphere HA agent is not reachable from vCenter Server

  • Проверки на соответствие образов vSphere Lifecycle Manager могут сбоить с неизвестной ошибкой вида:

Unknown error occurred when invoking host API

  • Включение vSphere HA сбоит с ошибкой конфигурации:

Cannot complete the configuration of the vSphere HA agent on the host. Applying HA VIBs on the cluster encountered a failure.

  • В клиенте vSphere можно видеть предупреждение о здоровье аппаратного обеспечения с Unknown-статусом.
  • Если диалоговое окно Edit NTP Settings только открывается и закрывается, опция «Start and stop» хоста выключается.
  • Операции снэпшотирования для ВМ с включенным Change Block Tracking (CBT) сбоят. Если отключить софтовый FCoE-адаптер, используемый для доступа к хранилищу Fibre Channel, CBT-модуль не способен загрузиться, и ESXi не в состоянии обнаружить загрузочное устройство.
  • Служба здоровья vSAN уходит в таймаут, если есть проблемы с интернет-подключением или разрешением DNS. Ошибка вида:

Unable to query vSAN health information. Check vSphere Client logs for details.

  • Хост vSAN падает в процессе удаления или декомиссования диска в фиолетовый экран. Записи вида:

2020-09-01T04:22:47.112Z cpu7:2099790)@BlueScreen: Failed at bora/modules/vmkernel/lsomcommon/ssdlog/ssdopslog.c:398 — NOT REACHED
2020-09-01T04:22:47.112Z cpu7:2099790)Code start: 0x418037400000 VMK uptime: 0:00:39:25.026
2020-09-01T04:22:47.112Z cpu7:2099790)0x451a8049b9e0:[0x41803750bb65]PanicvPanicInt@vmkernel#nover+0x439 stack: 0x44a00000001
2020-09-01T04:22:47.112Z cpu7:2099790)0x451a8049ba80:[0x41803750c0a2]Panic_vPanic@vmkernel#nover+0x23 stack: 0x121
2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049baa0:[0x4180375219c0]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x451a8049bb00
2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049bb00:[0x41803874707a]SSDLOG_FreeLogEntry@LSOMCommon#1+0x32b stack: 0x800000
2020-09-01T04:22:47.113Z cpu7:2099790)0x451a8049bb70:[0x4180387ae4d1]PLOG_RefDecLogEntryEx@com.vmware.plog#0.0.0.1+0x2e stack: 0x712d103
2020-09-01T04:22:47.114Z cpu7:2099790)0x451a8049bbe0:[0x4180387dd08d]PLOGCleanupLsnTable@com.vmware.plog#0.0.0.1+0x72 stack: 0x431b19603150
2020-09-01T04:22:47.114Z cpu7:2099790)0x451a8049bcd0:[0x4180387dd2d3]PLOG_CleanupLsnTables@com.vmware.plog#0.0.0.1+0x80 stack: 0x4318102ba7a0
2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049bd00:[0x4180387dabb5]PLOGRelogSM@com.vmware.plog#0.0.0.1+0x2ce stack: 0x800000
2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049beb0:[0x4180386de2db]VSANServerMainLoop@com.vmware.vsanutil#0.0.0.1+0x590 stack: 0x43180fe83380
2020-09-01T04:22:47.115Z cpu7:2099790)0x451a8049bf90:[0x4180375291ce]vmkWorldFunc@vmkernel#nover+0x4f stack: 0x4180375291ca
2020-09-01T04:22:47.116Z cpu7:2099790)0x451a8049bfe0:[0x4180377107da]CpuSched_StartWorld@vmkernel#nover+0x77 stack: 0x0

No related posts.