Изменение имени хоста VMware ESXi

Иногда возникают простые задачи, при решении которых возникают странные эффекты.

В нашей организации есть требование именовать все серверы по FQDN имени с указанием суффикса домена.

Но, как обычно, часть работничков на это дело забивает.

При инвентаризации хостов ESXi несколько таких замечаний было обнаружено. Для переименования воспользовались заметкой Changing the name of an ESX or ESXi host (1010821) и подали команды в SSH:

esxcli system hostname set --host=esxi-01.domain.local

В результате получили esxi-01.domain.local.domain.local ;). Ошибка была простая — указали параметру host имя с суффиксом домена.

Проверить каждый параметр можно одной командой:

esxcli system hostname get

Исправить ошибку можно двумя способами — задать fqdn или домен:

esxcli system hostname set --fqdn=fqdn

esxcli system hostname set --domain=domain

Lenovo ThinkSystem M.2 Mirror распадается на двое

Опыт эксплуатации серверов Lenovo ThinkSystem выявил одну болячку. При использовании M.2 Mirror комплекта для размещение гипервизора неожиданно виртуальный диск в RAID распадается на два — каждому накопителю свой виртуальный диск,  система сыпет ошибками.

Решение довольно простое — надо удалить второй дубликат в меню F1 Setup —> UEFI Setup —> System Settings —> Storage —> M.2 + Mirroring Kit Configuration Utility —> Virtual Disk Management и дождаться ребилда. Если диск не ребилдится, а пишет Foreign, то выбрать Import.

Проблеме уже года полтора, но только сейчас Lenovo официальное её признала, выпустив заметку в базе знаний M.2 + Mirror Kit RAID 1 splits into 2 foreign RAID 1 drives with possible rebuild failure — Lenovo ThinkSystem.

Для предупреждения необходимо обновить прошивку M.2 Mirror до версии v2.3.10.1194 (она же 2.3.10.1098).

Не работает мониторинг в vCenter Server Appliance

Встретилась проблема — раздел Monitor в VCSA не показывает новых данных. При этом в разделе Services служба VMware Appliance Monitoring Service находится в состоянии Stopped либо в консоли проверить статус службы vmware-statsmonitor:

service-control --status

Гугление подсказало решение — выставить время ожидания старта службы в 10 минут (предварительно сделать снимок VCSA — после проверки удалить):

  1. Подключиться по  SSH к VCSA, используя root.
  2. Изменить время ожидания:
    sed -i '/StartTimeout/d' /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json
    
    sed -i '/ApiHealthFile/a "StartTimeout": 600,' /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json
  3. Убить процесс
    kill -HUP $(cat /var/run/vmon.pid)
  4. Принудительно выполнить перезапуск сервиса
    /usr/lib/vmware-vmon/vmon-cli -k statsmonitor
    
    /usr/lib/vmware-vmon/vmon-cli -i statsmonitor
  5. Перезапустить VCSA и проверить через 15 минут, что VMware Appliance Monitoring Service запущен.

Минимальная рекомендуемая версия vHW

На днях озадачился проблемой минимальной версией vHW в ESXi.

Текущая ситуация с ESXi такова:

  1. ESXi 6.7 поддерживает vHW версий с 4 по 14 — Virtual machine hardware versions.
  2. vSphere 5.5 сошла с дистанции.
  3. В связи с Чипокалипсом минимальная рекомендуемая версия — 9, сильно рекомендуемая — 11: Hypervisor-Assisted Guest Mitigation for Branch Target injectionPerformance impact on VMware appliances after patching for Spectre/Meltdown.
  4. VCSA 6.7u1 использует Photon OS 1.0, который у нас не работает, если поднять версию старше 11.
  5. Есть непонятки с EVC Mode и vHW.
  6. UNMAP в тонких дисках поддерживается с версии vHW 11, для Linux с версии vHW 13.

В итоге мы ориентируемся на следующие версии (предварительно делается копия *.vmx либо бэкап ВМ, после повышения проверка, Upgrading a virtual machine to the latest hardware version (multiple versions)):

  1. Готовые Virtual Appliances и шаблоны виртуальных машин повышаются до версии 11.
  2. Целевая версия для Linux с тонкими дисками — 13 либо 14.
  3. Целевая версия для ПО, требующего новых инструкций CPU — 13 либо 14.
  4. В частных случаях смотрим на фунционал Hardware Features Available with Virtual Machine Compatibility Settings.

Обновление версии VCSA с 6.7 до 6.7 update 1

Ранее в бложике были описаны два сценария установки обновлений на VCSA 6.7:

Но, чтобы админы на работе не скучали, компания VMware стремится разнообразить способы обновления.

Для обновления VCSA 6.7  в режиме HA до версии 6.7 update 1 опубликована отдельная статья в БЗ VMware Changes in patching VCHA enabled vSphere 6.7 systems to any 6.7 update/patch release:

  1. Зайдите vSphere Client.
  2. Перейдите в Configure > vCHA.
  3. Нажмите Edit.
  4. Выберите «Remove vCenter HA».
  5. Обновите vCenter Server.
  6. Заново создайте vCHA.

После пары матюков в адрес разработчиков были выполнены данные рекомендации и осуществлена попытка обновить vCenter через VAMI (по инструкции для одиночного сервера), но установщик вставал на 73% и заваливал vCenter. После этого запущено обновление через CLI (один цикл из инструкции по обновление в конфигурации HA), которое прошло без сбоев.

EVC Mode и vHW

Заметил странный факт, что на процессорах Skylake и гипервизоре ESXi 6.7u1 «не отрабатывает» EVC Mode, выставленный в  Skylake — все машины стоят в режиме Broadwell.

Обратил внимание, что у нас 80% виртуальных машин работают на virtual hardware(vHW)  версии 11, он же Compatibility: ESXi 6.0 and later (VM version 11).

Предположил, что данный уровень дополнительно ограничивает уровень ЦПУ, хотя в EVC and CPU Compatibility FAQ и Enhanced vMotion Compatibility (EVC) processor support ничего про такое поведение не заметил.

Решил пойти опытным путём — создал ВМ и прогнал все версии vHW c 4 до 14. В результате выявилось, что ВМ с vHW от 4 до 12 имеют максимальный EVC Mode -Broadwell, а ВМ с vHW равным 13 или 14 могут быть в режиме Skylake.

Ошибка при обновлении Custom Image VMware ESXi «The upgrade has VIBs that are missing dependencies»

Для большей совместимости со своим оборудованием производители серверов выпускают преднастроенные образы ESXi.

Проблемы возникают при попытке перейти с версии на версию ESXi с помощью Update Manager — вылазят ошибки с таким текстом:

The upgrade has VIBs that are missing dependencies:
..
Remove the VIBs or use Image Builder to create a custom upgrade ISO image that contains the missing dependencies, and try to upgrade again.

При попытке заменить образ ESXi 6.0 от IBM на образ ESXi 6.7 от Lenovo получил охапку конфликтов с различными утилитами для железяк: Читать далее «Ошибка при обновлении Custom Image VMware ESXi «The upgrade has VIBs that are missing dependencies»»

Обновление VMware vCenter 6.7 в конфигурации HA

Процесс обновления VMware vCenter 6.7 в конфигурации HA примерно на порядок сложнее, чем Обновление одиночного VMware vCenter 6.7

Есть вариант прикурить с документацией (для неизвестной версии vSphere) в виде статьи Patch a vCenter High Availability Environment.

Рекомендую следующий процесс (клиент vSphere Web Client — Flex):

  1. Авторизуемся в My VMware.
  2. Открываем VMware Patch Download Center и выбираем патчи для VC 6.7.0 и качаем самый новый ISO.
  3. Переводим vCenter HA в Maintenance Mode (встать на объект vCenter->Configure->vCenter HA ->Edit->Maintenance Mode):
    Читать далее «Обновление VMware vCenter 6.7 в конфигурации HA»

Обновление одиночного VMware vCenter 6.7

Обновление одиночного VMware vCenter 6.7 представляет собой очень простую задачу, для реализации которой следует выполнить следующие действия:

  1. Открыть vCenter Appliance Management на закладке Update по адресу https://vcenter:5480/ui/update.
    Читать далее «Обновление одиночного VMware vCenter 6.7»

Удаление сломанного HA из VCSA 6.7

У меня случилась поломка — при обновлении vCenter Server Appliance High Availability (VCSA HA) версии 6.7 случайно перезагрузил ноду Witness, которая обновлялась.  В итоге получил ноды VCHA с разными версиями и невозможностью накатить обновление на Witness.

Через GUI все операции с HA заблокировались и ничего не давали сделать. Поиск подсказал, что надо разрушить VCSA HA — описание процедуры в документации Recovering from Isolated vCenter HA Nodes.

Удалил виртуальные машины Passive и Witness нод и приступил к «разрушению» HA-конфигурации.

Вот только результат ввёл в ступор:

root@vcenter [ ~ ]# destroy-vcha -f
-bash: destroy-vcha: command not found

Полные непонятки — везде даётся несуществующая команда.

Поискал другие статьи на тему HA, нашёл команду vcha-reset-primary.

Решил попробовать vcha-destroy -f.

Оно!