Mister Nobody – Page 20

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

1	service-control --status

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

Подключиться по SSH к VCSA, используя root.

Изменить время ожидания:

sed -i '/StartTimeout/d' /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json

sed -i '/ApiHealthFile/a "StartTimeout": 600,' /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json

sed -i '/StartTimeout/d' /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json

sed -i '/ApiHealthFile/a "StartTimeout": 600,' /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json

Убить процесс

kill -HUP $(cat /var/run/vmon.pid)

1

kill -HUP $(cat /var/run/vmon.pid)
Принудительно выполнить перезапуск сервиса

/usr/lib/vmware-vmon/vmon-cli -k statsmonitor /usr/lib/vmware-vmon/vmon-cli -i statsmonitor

1
2
3

/usr/lib/vmware-vmon/vmon-cli -k statsmonitor

/usr/lib/vmware-vmon/vmon-cli -i statsmonitor
Перезапустить VCSA и проверить через 15 минут, что VMware Appliance Monitoring Service запущен.

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

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

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

ESXi 6.7 поддерживает vHW версий с 4 по 14 – Virtual machine hardware versions.
vSphere 5.5 сошла с дистанции.
В связи с Чипокалипсом минимальная рекомендуемая версия – 9, сильно рекомендуемая – 11: Hypervisor-Assisted Guest Mitigation for Branch Target injection, Performance impact on VMware appliances after patching for Spectre/Meltdown.
VCSA 6.7u1 использует Photon OS 1.0, который у нас не работает, если поднять версию старше 11.
Есть непонятки с EVC Mode и vHW.
UNMAP в тонких дисках поддерживается с версии vHW 11, для Linux с версии vHW 13.
Поддержка Per-VM EVC требует vHW версии 14.
Поддержка Secure Boot требует vHW версии 13.
Поддержка Dynamic DirectPath требует vHW версии 17.
Поддержка Virtual NUMA Topology и Virtual HT требует vHW версии 20.

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

Готовые Virtual Appliances и шаблоны виртуальных машин повышаются до версии 11 либо 14.
Целевая версия для Linux с тонкими дисками – 14 либо 17.
Целевая версия для ПО, требующего новых инструкций CPU – 14 либо 17.
В частных случаях смотрим на фунционал Hardware Features Available with Virtual Machine Compatibility Settings и 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:

Зайдите vSphere Client.
Перейдите в Configure > vCHA.
Нажмите Edit.
Выберите “Remove vCenter HA”.
Обновите vCenter Server.
Заново создайте 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.