Author: Mister Nobody

Список проверок vSphere Health

При подключении к Программе повышения эффективности работы заказчиков (Customer Experience Improvement Program, CEIP), вы может проверить здоровье вашей vSphere через онлайн-анализатор.

Проверки с проблемами пишутся все, а вот беспроблемные только частично. Меня интересовало – что ещё проверяется?

Итак список проверок на момент публикации статьи:

  1. ESXi host with i40e driver and TCP Segmentation Offload
    (TSO) enabled KB 2126909
  2. ESXi with HP ILO driver version 10.0.1-24 KB 2148123
  3. Intel IOMMU interrupt remapper is disabled for ESXi hosts on
    HP ProLiant Gen8 servers KB 2149043
  4. ESXi host dvfilter vmci socket deregistration KB 2149242
  5. ESXi 6.0 Update 2 when hardware Large Receive Offload
    (LRO) is ‘enabled KB 2144968
  6. Network redundancy check when configuring VMware High
    Availability in vCenter Server KB 1004700
  7. ESXi 6.5.x has 10Gb Physical Nic and NetQueue is enabled KB 2151749
  8. ScratchConfig.CurrentScratchLocation is set to “/scratch” on
    ESXi version 6.0.0 and 6.5.0 KB 2151209
  9. ESXi maximum number of supported storage devices KB 2150280
  10. ESXi 6.5 or 6.7 host with IPv6 disabled KB 2150794
  11. ESXi system logs on vSAN datastore KB 2147541
  12. ESXi host with native Intel X710 driver and VLAN tagging KB 2149781
  13. ESXi with bad brcmfcoe or lpfc driver versions KB 2151391
  14. SearchLow I/O performance using intel-nvme drivers 1.3.2.8-
    1OEM and 1.3.2.4-1OEM with block sizes larger than 4K KB 55693
  15. Host experiences PF Exception 14 with
    bnx2x_netq_free_rx_queue_single in backtrace KB 53353
  16. Virtual machine operations on an ESXi 6.0 host fails KB 2113450
  17. Sequential-context attack vector vulnerability in Intel
    processors KB 55806
  18. Concurrent-context attack vector vulnerability in Intel
    processors KB 55806
  19. ESXi unable to save hostd service state to /bootbank KB 2057826
  20. VMDK corruption after canceling a snapshot removal task KB 2146319
  21. Disk space check for VMware vCenter Server Appliance KB 2145603
  22. vMotion network configuration check for vSphere Standard
    Switch KB 2120640
  23. vMotion network configuration check for vSphere Distributed
    Switch KB 2120640
  24. Selective deletion of tasks, events, and historical performance
    data in vSphere 5.x and 6.x KB 2110031
  25. Host participating in VM-based replication KB 55650
  26. ESXi on host with AMD EPYC 7xx1 CPU KB 52045
  27. vMotion of virtual machines from ESXi 6.0 to 6.5 KB 59723
  28. End of General Support for vSphere 6.0 KB 66977
  29. Deprecation of the external Platform Services Controller
    deployment model KB 60229
  30. Maximum number of ESXi hosts per cluster Max Config
  31. ESXi host connectivity with vCenter Server KB 1005757
  32. Enable SCAv2 for optimal hyperthreading performance KB 55806
  33. Unsupported address family with dvSwitch in ESXi 6.0 KB 2117308
  34. Host PSOD on QFLE3I driver on QLogic 57840 10/20 Gigabit
    Ethernet Adapter KB 56357
  35. vCenter Server version compatibility check KB 68174

VMware vSphere 6.7 Update 3 Alarm ‘Host hardware sensor state’

У VMware есть привычка в практически каждый релиз заложить какую-нибудь граблю. Вот и в vSphere 6.7 Update 3 отличились.

Выражается в виде массовых событий типа error в vCenter Events:

Функционал вроде бы не нарушен, проявляется на оборудовании разных производителей,  но эти же события имеют тип info в ESXi.

Проблема в том, что данные события переполняют логи vCenter и систем мониторинга.

Участник Reddit пишет:

Our vCenter daily log is usally something like 15-20KB, but it has blown up to 1.7-2.3 GB since the 10-node upgrade.

То есть рост логов в сутки составил всего-то сто тысяч(!) раз.

А что поддержка? Ничего – ещё не признали проблему! Видать, все на VMWorld уехали.

Update

VMware признала проблему и предложила пару обходных решений в базе знаний – Excessive Hardware health alarms being triggered for “Sensor -1 type” on ESXi hosts running vSphere 6.7 U3 (74607).

Останов VCSA при нехватке места

У нас неожиданно стал прекращать работать VCSA, а конкретно сервис VPXD.

Стартнёшь ручонками – работает то десяток часов, то 20 минут. Из warning’ов – мало места для базы данных (List of VMDKs/Partitions for a vCenter Server Appliance 6.7 – Size Mount point and Purpose (70625)). VAMI показывает, что места в SEAT занято 90%. Также не работает Update Manager даже при запущенном VPXD. Все логи vpxd.log перебрали – ничего не заметили, как будто штатный останов.

Написали в техподдержку – те попросили логи собрать, а как их соберёшь, если vCenter то потухнет, то погаснет. Кое-как собрали через VAMI, да и те оказались не полные, пришлось ручонками скопировать с помощью WinSCP папку логов VPXD.

Поддержка логи смотрела внимательнее и нашла:

Действительно, места не хватает и VPXD сам себя отправляет отдыхать.  Описание поведения vCenter есть КБ-шечке “Shutting down the VC as there is not enough free space for the Database” error (67017).  Вот только она про /storage/db, а про /storage/seat умалчивает.

Добавили место у диска SEAT по инструкции Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.5 and 6.7 (2145603). Перезагрузили VCSA и всё заработало.

P.S. Так и не понял – с каких пор 90%=>95%?

P.P.S. Андрей подсказал откуда разница в процентах (данные после увеличения диска):

Вывод в VAMI: seat Total space 54.0 GB  Used space 32.4 GB Available space 21.6 GB 60.1% of 54.0 GB

Вывод в df -h: /dev/mapper/seat_vg-seat 55G 33G 19G 64% /storage/seat

Доступность инструкций процессора в зависимости от версии vHW

Ранее на бложике публиковались две статьи о разном поведении виртуальных машин при разном vHW и EVC

  1. Минимальная рекомендуемая версия vHW
  2. EVC Mode и vHW

Один из участников сообщества VMUG провел анализ доступных инструкций процессора в зависимости от версии виртуального железа с помощью утилиты /proc/cpuinfo. В результат появилась занимательная таблица:
vHW CPU flags Исходник в Google Таблицы.

P.S. Комментарий автора:

После обсуждения CPUID решил проверить зависимость доступных инструкций от vHW, но основной вывод уже был сделан в КВ по процессорным уязвимостям: “безопасной” версией является 9, а тормозить оно перестаёт на 11. Также выяснилось:
1. vHW режет флаги не так сильно, как EVC. Например, на vHW=8 доступны fma и movbe (Haswell), а на vHW=13 доступны xsavec и xsaves (Skylake).
2. Между 13-16 версиями без NVDIMM и гостевой виртуализации нет разницы.

Релиз платформы VMware vSphere 6.7 Update 3

Компания VMware выпустила обновление своей платформы виртуализации VMware vSphere 6.7 Update 3:

VMware ESXi 6.7 Update 3 Release Notes

VMware vCenter Server 6.7 Update 3 Release Notes

VMware vSAN 6.7 Update 3 Release Notes

vSAN 6.7 U3 Technical Overview

New Release: PowerCLI 11.4.0

vSphere Client Plugins: What’s New in 6.7 Update 3

VCSA VAMI переключается на “Installation in progress”

При попытке обновления VCSA он завис на тексте:

Подождав довольно долго, я понял, что ему так не помочь. Подключился по SSH и обновил через CLI.

Всё прошло гладко, но при подключении к VAMI каждый раз шло перенаправление на страницу /update/progress c тем же текстом:

Робот в поддержке предложил статью Accessing the VAMI returns error “Update installation in progress” after recovering from a failed update (67179), советом из которой я и воспользовался:

  1. Подключить к VCSA по SSH
  2. Проверить содержимое файла “/etc/applmgmt/appliance/software_update_state.conf”. Должно быть примерно такое содержимое:
  3. Сделать копию файла “/etc/applmgmt/appliance/software_update_state.conf”
  4. Остановить сервис applmgmt командой: service-control –stop applmgmt
  5. Удалить файл “software_update_state.conf”
  6. Запустить сервис applmgmt командой: service-control –start applmgmt
  7. Зайти на VAMI для проверки

Данные о ВМ в vMotion Wizard

Про полезняшки в новых версиях vSphere мы уже писали ранее: о флешовом клиенте в статье  Фильтры, задания и снимки в VMware vSphere 6.7, о ESXi-ом клиенте в Просмотр логов на ESXi.

Сегодня заметка о новой фишке vMotion Wizard – VM origin.

Часто бывает, что запустил перемещение виртуальной машины со сменой хоста и хранилища и тут приходит мысль “а сейчас-то как машина размещена?”.

Разработчики HTML5-клиента решили это дело упростить и сделали подсказку – достаточно щёлкнуть VM origin:

Видеозаписи докладов VeeamON Forum Россия 2019

Для тех, кто не смог посетить VeeamON Forum Россия 2019 доступны видеозаписи докладов

The Premier Forum for Cloud Data Management

Доклады, которые впечатлили меня больше всего:

Быстрое восстановление с PureStorage ObjectEngine. Пришли времена когда бэкапы заказчики сохраняют на флеши(!!!) и в облако, происходит переход от схемы disk2disk2tape на схему flash2flash2cloud. Доклад офигенно ломает стереотипы.

Тонкости проектирования комплексной платформы Veeam с более 25.000 виртуальных машин. Докладчик рассуждает о масштабируемости инфраструктуры VBR для гигантской виртуальной среды. Из доклада становится понятна логика – какого чёрта так много ресурсов нужно бэкапам.

Как минимизировать человеческий фактор при DR-сценарии? VAO 2.0 – новые возможности! Классика жанра – контрмеры при авариях надо планировать заранее, а не во время аварии!

Доступность данных. Ожидания и реальность. Довольно бизнесовый доклад, но для меня открыл существование методологии, о которой я догадывался интуитивно, Business Impact Analysis.

Также вам могут быть интересные и другие темы.

Приглашаем на VeeamOn в Москве 6 июня 2019 года

VeeamON Forum Россия 2019 состоится в Москве 6 июня в Отеле Хаятт Ридженси Москва Петровский Парк.

Приглашаем ознакомиться с программой, зарегистрироваться и участвовать!

Обращаю внимание, что программа состоит из 2 направлений:

  • Управление данными в облаке
  • Непрерывность бизнеса