Обновление серверов Dell с помощью VMware LifeCycle Manager

Мы ранее уже делились опытом обновления серверов Lenovo, теперь настала очередь Dell.

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

Вам потребуется Dell OpenManage Integration for VMware vCenter aka OMIVV, который можно скачать отсюда. Начиная с версии 5.3, присутствует поддержка VMware vSphere 7.0 U2.

OMIVV поставляется в виде виртуального апплайнса. Сразу после установки работает пробная лицензия на 5 хостов и 15 серверов vCenter.

Лицензируется продукт по хостам, доступны 3-х и 5-летние пакеты.

После установки необходимо зарегистрировать в OMIVV vCenter и vLCM, поддерживается одновременная работа с 15 vCenter-серверами.

Читать далее «Обновление серверов Dell с помощью VMware LifeCycle Manager»

Обновляем серверы Lenovo Thinksystem/ThinkAgile VX с помощью VMware vSphere Lifecycle Manager

В VMware vSphere 7.0 появился новый встроенный продукт для управления обновлениями Lifecycle Manager. Кратко я о нём упоминал в статье:

VMware ESXi 7.0 и неподдерживаемое оборудование

Данный менеджер умеет проверять HCL и даже, по слухам, обновлять прошивки оборудования!

После несколько обращений по поводу функционала и неполным пониманием собеседников как это работает настало время написать про интеграцию с экосистемой Lenovo. Читать далее «Обновляем серверы Lenovo Thinksystem/ThinkAgile VX с помощью VMware vSphere Lifecycle Manager»

Переход на VMware vSphere 7.0 update 2

Постоянный читатель прислал свои мысли о выборе гипервизоров и убедительной победе vSphere 7.0, несмотря на все грабли ;).

С чего все началось

Недавно у наших коллег появилось осознание, что:

  1. самым старым серверам в продуктивной среде уже 8 и больше лет,
  2. поддержки и запчастей на них нет,
  3. нагрузка по памяти под 90%, но ее там очень немного,
  4. установлена максимально возможная для этих серверов ESXi 6.5 , на тот момент 17477841 (сейчас 18071574).

Поэтому  было решено:

  1. начать закупку новых серверов,
  2. обновить, где  возможно, до ESXi 7.0 для единообразия.

Серверы, в основном, производства HPE и Huawei, на каких-то задачах используются серверы Supermicro. Предлагают закупать Dell, HPE, Lenovo. У Huawei сейчас все сложно, а присматриваться к линейке Kunpeng на Arm сейчас нет времени. Хотя под Arm есть и MS Server, и ESXi.

Почему ESXi, а не что-то еще Читать далее «Переход на VMware vSphere 7.0 update 2»

Порядок восстановления ИТ-инфраструктуры

Однажды поручили разработать нам DRP (Disaster Recovery Plan) — План восстановления деятельности после кризисной ситуации. План как план, таких мильон.

Но один раздел запал мне в душу — Порядок восстановления ИТ-инфраструктуры.

В моём видении, базирующемся на опыте переездов ЦОДов, порядок получился таким: Читать далее «Порядок восстановления ИТ-инфраструктуры»

Любимые наши группы в Telegram

Рекомендую подписаться на следующие группы в Telegram для получения широкой экспертной поддержки:

    1. VMware User Group Rus
    2. VMware vSAN
    3. vRealize User Group
    4. VMware Workspace ONE
    5. NSX & SD-WAN User Group
    6. Tanzu VMware Kubernetes
    7. VMware Cloud Director
    8. Russian Backup User Group
    9. Storage Discussions
    10. Storage Discussions NAS
    11. Hyper-V

При вступлении в группы осмотритесь, оцените обстановку и не забудьте ознакомиться с правилами задавания вопросов.

VMware vSphere Quick (Re)Boot

В платформе VMware vSphere 6.7 появилась технология vSphere(ESXi) Quick Boot, предназначенная для быстрой перезагрузки ESXi хостов во время обновлений с помощью vSphere Update Manager.

Технология требует соблюдения нескольких условий, описанных в БЗ Understanding ESXi Quick Boot Compatibility (52477):

  1. Модель сервера находится в VMware HCL (функция QuickBoot для ESXi 7.0+)  либо хранится локально в ESXi 6.7 в текстовых файлах.
  2. Выключена технология TPM.
  3. Нет passthru-устройств, подключенных к ВМ с хоста.
  4. Не загружены vmklinux-драйверы на хосте.

В vSphere 7.0 третье ограничение снято, а четвертое отсутствует архитектурно.

Для проверки можно использовать локальный скрипт, выводящие информацию о совместимости модели сервера и драйверов:

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

Пример вывода на стендовом хосте:

LoadESX is not compatible with vmkLinux drivers.
This platform (IBM:System x3650 M2 -[794744G]-) is not compatible with loadESX.
Compatibility check failed: violating one or more strict requirements (loadESX is not supported on this machine)

Для быстрого обновления хостов технология включается в vSphere 7+ Menu->Lifecycle Manager-> Images/Baselines Remediation Settings->Quick Boot. Сокращение времени установки равно времени проверок UEFI при полной перезагрузке хоста.

Также меня заинтересовала возможность быстрой перезагрузки хостов без применения обновлений, поиск в интернете выявил два схожих варианта.

Вариант с Reddit:

/bin/loadESXEnable -e
/usr/lib/vmware/loadesx/bin/loadESX.py
reboot

Вариант от Jiří Viktorin:

/bin/loadESXEnable -e
/usr/lib/vmware/loadesx/bin/loadESXShutdown.sh prepare
reboot

Прошу проголосовать за добавление функционала в графический интерфейс на портале по сбору идей vSphere Ideas, авторизация стандартная от vmware.com.

Хождение по граблям VMware vSphere 7.0

Цикл статей о борьбе с VMware vSphere 7.0 продолжается. Читайте содержимое предыдущих серий:

Обновление IBM/LENOVO System X M5 Embedded Hypervisor on SD-card до версии ESXi 7.0

Обновление VMware vCenter с версии 6.7 до 7.0

VMware ESXi 7.0 и неподдерживаемое оборудование

Снимки ВМ и NetApp FAS ONTAP

Самая жёсткая проблема, с которой столкнулись — это переход LUN’ов на системе хранения NetApp FAS в режим Offline при попытке сделать снимок из-под vSphere 7.0 с ошибкой «Out of space».

Предположительно, проблема связана с All Flash LUN’ами, созданными в ONTAP версии 9.1 или 9.2. Проблема наблюдается в ONTAP 9.7P4, более поздние патчи не проверяли.

Для нас пока закончилось падением пары продуктивных баз данных при инициации резервного копирования.

Решение проблемы:

  1. Вернуть LUN в Online.
  2. Если при Rescan Storage не вернулось DataStore на хостах, то перезагрузить хосты.
  3. Смигрировать ВМ на другой LUN.
  4. Пересоздать проблемный LUN (*либо устранить корневую причину).
  5. Смигрировать ВМ обратно.

vLCM Image и Intel VMD NVMe Driver

Самая весёлая проблема, которая убила кучу времени.

При переводе кластеров с модели обновления Baseline на модель обновления Image поймали отличный конфликт компонентов там, где не ожидали.

Про драйвер читать в статье:

VMware ESXi, VSAN и Intel VMD-Enabled NVMe Driver

На текущий момент в VSAN HCL рекомендуется версия драйвера intel-nvme-vmd-2.0.0.1146, в стандартном же образе зашит другой драйвер iavmd 2.0.0.1055-3vmw.700.1.0.15843807. При попытке собрать образ, совместимый с VSAN HCL получаем невозможность установить компоненты HA. Валят скопом такие ошибки:

  • vSphere HA host status/Cannot find HA master agent
  • vSphere HA agent for this host has an error: vSphere HA agent cannot be installed or configured
  • Component vsphere-fdm cannot be found in depot
  • ‘vxd’ service, runnig on ‘cluster’, reported issue: The HA constraints in the image spec have version whereas the expected version is 7.0.0.-16386338

Решение проблемы:

  1. Отключить HA.
  2. Добавить в image драйвер intel-nvme-vmd-2.0.0.1146.
  3. Накатить на  хост image.
  4. Убрать из image intel-nvme-vmd-2.0.0.1146.
  5. Включить HA.

В итоге, проходим проверку на VSAN HCL и получаем Warning при проверке Image Compliance.

Update 11092020. 10.09.2020 драйвер iavmd 2.0.0.1055-3vmw.700 добавлен в VSAN HCL.

Image не накатывается на хосты

Ещё одна весёлая проблема, при попытке пройти проверку или накатить Image получаем шедевральную ошибку:

Unknown error occurred when invoking host API.

Самое тупое решение:

  1. Cделать сброс БД менеджера обновлений —  Resetting VMware Update Manager Database on a vCenter Server Appliance 6.5/6.7/7.0 (2147284).
  2. Перезагрузить хост.
  3. Запустить обновление снова.

Не работает vLCM Image Export

Для переноса сборки Image между кластерами или vCenter разработчики предусмотрели вариант выгрузки собранной вами конструкции.

Существует три варианта экспорта:

А теперь о проблеме: если вы используете свои сертификаты, то ни одна опция не работает, происходит ошибка браузера «ERR_SSL_PROTOCOL_ERROR».

Решение проблемы, конкурирующие с предыдущим по интеллектуальности и попахивает уязвимостью (неавторизованный доступ):

  1. Скопировать ссылку из адресной строки браузера.
  2. Открыть приватное окно.
  3. Вставить ссылку в адресную строку.
  4. Заменить протокол с https на http и получить ожидаемое.

Обновление IBM/LENOVO System X M5 Embedded Hypervisor on SD-card до версии ESXi 7.0

Семейство серверов IBM/LENOVO System X  серии M5 может иметь предустановленный Embedded Hypervisor на SD-карте с совместимой версией ESXi 6.x.

При попытке обновиться до версии ESXi 7.0 выходит ошибка:

The boot disk has a size of 1024MB, the minimum requirement of the upgrade image is 3814MB.

Управление SD-картой осуществляется в интерфейсе IMM2. Анализ адаптера показывает, что в реальности используются 32 ГБ карты, но на заводе создан виртуальный диск на 1 ГБ. Расширение размеров не поддерживается.

Для установки ESXi 7.0 придётся прибегнуть к обходной схеме:

  1. Сделать резервную копию конфигурации ESXi — подробно описано в How to back up ESXi host configuration (2042141).
  2. Переформатировать SD-карту на 30 ГБ (максимально доступный размер).
  3. Установить чистый ESXi 6.x (версии, с которой снята резервная копия).
  4. Настроить сеть.
  5. Восстановить из резервной копии конфигурации по инструкции из пункта 1.
  6. Накатить обновление до ESXi 7.x.

P.S. Возможно, данная проблема встречается и на серверах других производителей с предустановленным гипервизором.

VMware ESXi 7.0 и неподдерживаемое оборудование

Disclamer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки VMware. Любое использование оборудования вне VMware HCL может быть использовано только на свой страх и риск. В статье рассматривается только то оборудование, на котором возможен технический запуск ESXi 6.7U3.

В связи с выходом платформы VMware vSphere 7.0 виртуальные системные администраторы стали анализировать возможность обновления либо внедрения данного продукта.

Если проблемы с vCenter 7.0 вполне решаемы и описаны в нашей статье Обновление VMware vCenter с версии 6.7 до 7.0, то с ESXi 7.0 всё не так просто.

Для «упрощения» работы администраторов VMware расширила функциональность Update Manager (VUM) полуавтоматическим анализом оборудования: сверкой моделей серверов с HCL, проверкой версий прошивок и драйверов компонентов. Данная функциональность уже была частично представлена  в VSAN [Skyline] Health Hardware compatibility для дисковой подсистемы. Новая версия VUM стала называться vSphere Lifecycle Manager (vLCM). Для загрузки HCL следует в административном интерфейсе нажать ACTIONS->Sync HCL.

Мои ожидания от vLCM были примерно такие — запускаю на хосте Updates -> Hardware Compatibility и система пишет, что оборудование не в HCL, такие-то компоненты не имеют драйверов и не будут работать. В реальности, если сервер не в HCL, то на этом проверка останавливается:

Host model is not compatible with ESXi 7.0
Skipped checking host devices.

Что как бы нас совершенно не устраивает, так как наша цель — запуститься вне HCL, и хотелось бы понимать какие компоненты не имеют драйверов и поддержки.

Поэтому с компонентами придётся разбираться самостоятельно. Читать далее «VMware ESXi 7.0 и неподдерживаемое оборудование»

HPE MSA Analyzing Tool

Всем привет!

HPE выпустила онлайн-утилиту по анализу конфигурации и прошивок для массивов MSA, начиная с третьего поколения (HPE MSA P2000 G3).

Собираете логи массива, загружаете на портал и «вжух» — получаете набор рекомендаций по настройкам и прошивкам.

Ниже я привожу выдержки из отчёта с одной из моих MSA:

Читать далее «HPE MSA Analyzing Tool»