Почему в vCenter 9 ещё видны Baselines, но обновить через них хост до ESX 9 уже нельзя

В vCenter 9.0 бейзлайны остались только для патчей хостов 8.x и стороннего ПО: апгрейд до ESX 9 через них не поддерживается, ISO не импортируется. Путь один — перевести кластер на образ vLCM. Рассказываю, как понять режим кластера, собрать образ из офлайн-бандлов и не потерять вручную поставленные драйверы.

Что в vCenter 9.0 осталось от Baselines и что уже не работает

Первое, что сбивает с толку: интерфейс никто не убирал. В vCenter 9.0 Lifecycle Manager по-прежнему показывает Baselines и Baseline Groups, старые бейзлайны лежат на месте, а кластер, который жил на VUM, после апгрейда vCenter так и остаётся на бейзлайнах. Ничего само не мигрировало. Отсюда логичный, но неверный вывод: «раз всё на месте, обновимся по-старому». С этим выводом ко мне в обслуживание инфраструктуры приходят чаще всего — уже после неудачного окна работ.

На деле документация vSphere 9.0 оставляет бейзлайнам ровно две задачи: обновлять и патчить хосты версии 8.x и ставить на хосты стороннее ПО. Использование бейзлайнов для апгрейда кластеров и отдельных хостов в vCenter 9.0 объявлено deprecated, а для перехода на ESX 9.0 кластер обязан управляться образом. Broadcom свела перечень ограничений в KB 379388, и читать его стоит до планирования работ, а не в ночь окна.

Конкретно на практике упираешься в три вещи. Импорт ISO в Lifecycle Manager в vCenter 9.0 не поддерживается — это отдельно зафиксировано в KB 419331, поэтому привычный upgrade-бейзлайн с ISO не собрать. Апгрейд хоста до девятки из кластера на бейзлайнах не стартует: мастер требует сначала перевести кластер на образ. А хосты, которые уже на ESX 9, обслуживаются образом, а не бейзлайнами.

Что осталось живым: хост 8.x в кластере на бейзлайнах патч-бейзлайнами обновляется до другого 8.x, и стороннее ПО ставится как раньше. То есть если у вас vCenter 9.0 и хосты 8.0 U3, вы не в аварии: закрывать уязвимости восьмёрки можно, а переход на образы — плановая задача.

• Работает: патчи 8.x → 8.x бейзлайнами, установка стороннего ПО и драйверов
• Не поддерживается: импорт ISO в Lifecycle Manager vCenter 9.0
• Не стартует: апгрейд до ESX 9 из кластера на бейзлайнах
• Хосты ESX 9.x: только управление образом vLCM

Чем образ vLCM отличается от бейзлайна и почему это важно

Бейзлайн — императивная штука: набор бюллетеней, которые надо доложить поверх того, что уже стоит на хосте. Что там стоит сейчас, бейзлайн не знает. Отсюда классическая болезнь ферм, которые лет пять жили на VUM: три хоста в одном кластере, все «зелёные» по compliance, а по факту у одного драйвер HBA от вендорского бандла двухлетней давности, у второго — ручной VIB от инженера, который давно уволился. Собрать их в одинаковое состояние бейзлайнами нельзя, можно только докладывать сверху.

Образ vLCM — декларативная модель. Вы описываете целевое состояние хоста целиком: базовая версия ESX, vendor add-on, дополнительные компоненты (драйверы, агенты), прошивки через Hardware Support Manager. Remediation не докладывает, а приводит хост к описанию: ставит недостающее и, что важнее, удаляет лишнее. Один образ на кластер — значит, все хосты идентичны, и дрейф конфигураций закрывается архитектурно, а не дисциплиной админа.

Спорить с этим решением бессмысленно, но и восторгаться нечем. Модель образов честно лучше для однородной фермы на брендовом железе. Она заметно неудобнее там, где парк собран из того, что было: разные поколения серверов в одном кластере, кастомные VIB, дополнительные сетевые карты с драйверами не из вендорского бандла. Именно там переход и ломается, об этом ниже.

И ещё одно свойство, которое многие узнают слишком поздно: после перевода кластера на образ вернуть его на бейзлайны нельзя. Документация говорит прямо: можно перенести хосты в другой кластер на бейзлайнах, но сам кластер обратно не переключается. Это односторонняя дверь.

• Бейзлайн: «доложить бюллетени поверх», текущее состояние хоста не учитывается
• Образ: «привести хост к описанию», лишнее удаляется
• Один образ на кластер — хосты гарантированно одинаковые
• Переход на образ необратим для кластера

Разбор из практики: «Рубль к рублю», три хоста и чужой апгрейд vCenter

Финансовое консультирование «Рубль к рублю», 38 рабочих мест. Ферма в арендованной стойке: кластер PROD из трёх Dell PowerEdge R650 на ESXi 8.0 U3 и отдельный хост R640 под резервное копирование, всё под vCenter 8.0 U3. С 2022 года — VUM и три бейзлайна: критические патчи, некритические и upgrade-бейзлайн с ISO. На кластере крутятся 1С, терминальный сервер, файловый сервер и контроллеры домена.

Летом прежний подрядчик поднял vCenter до 9.0 «чтобы было актуально» и на этом исчез. Задача перешла к нам: обновить хосты, потому что на восьмёрке накопились патчи безопасности, а у клиента была действующая подписка на девятку. Заходим: бейзлайны живы, compliance считается. Пробуем импортировать ISO ESX 9.0 — операция не поддерживается. Пробуем старый upgrade-бейзлайн — remediate не проходит предпроверку. Срочные уязвимости восьмёрки мы закрыли штатным патч-бейзлайном за одно окно, а план «девятка за ночь» переписали целиком.

Инвентаризация перед переходом показала вот что. На одном хосте кластера стоял вручную поставленный VIB драйвера HBA — меняли контроллер в 2024-м. На двух — агент мониторинга, которого нет в вендорском add-on. На R640 — драйвер дополнительной 10-гигабитной карты от её производителя, тоже ручной VIB. Прошивки BIOS на трёх R650 разъехались на две версии. Ни один из этих фактов не был записан ни в одном документе клиента.

Итоговая последовательность: сначала перевели кластер на образ с той же версией 8.0 U3, что стояла на хостах — это чистое выравнивание без апгрейда. Образ собрали из базового ESX, add-on Dell и двух дополнительных компонентов (драйвер HBA и драйвер 10G), агент мониторинга сознательно убрали и заменили сбором по SNMP. Прогнали Check Compliance, remediation по одному хосту в режиме обслуживания с DRS в Fully Automated. Через неделю наблюдения сменили в образе базовую версию на 9.0 и прошли кластер ещё раз. Отдельный R640 перевели последним, эвакуируя ВМ вручную через vMotion. Простоя продуктивных ВМ не было.

Что я вынес из этого проекта для себя. Первое: два прохода — выравнивание на 8.0 U3, затем смена базовой версии — стоят лишнего окна на хост, но разделяют риски. Если после первого прохода что-то ломается, вы точно знаете, что виноват состав образа, а не новая версия ESX. Второе: решение по каждому нештатному VIB должно быть записано и подписано. Агент мониторинга мы убрали осознанно, с заменой на SNMP, и клиент об этом знал заранее, а не узнал по пропавшим графикам. Третье: апгрейд vCenter «для актуальности» без плана по хостам — худший порядок из возможных. Он ничего не дал клиенту, зато закрыл привычный путь обновления и превратил плановую задачу в срочную.

• Календарно: 12 дней, из них 5 — инвентаризация и сборка образа
• Окна работ: 9 ночных окон по 1–1,5 часа — одно на патчи и по четыре на каждый проход
• Найдено нештатного: 4 ручных VIB, разъезд BIOS на 2 версии
• Простой ВМ: 0, DRS Fully Automated, по одному хосту
• Не по плану: Quick Boot на одном хосте не прошёл проверку совместимости — полная перезагрузка, +15 минут

Как узнать, на бейзлайнах кластер или на образе

Глазами — в vCenter: кластер → Updates. Если там блоки Baselines в привычном виде, кластер на бейзлайнах. Если видите Image с полями ESX Version, Vendor Addon, Firmware and Drivers Addon, Components — кластер уже на образе. Но по нескольким кластерам кликать долго, проще одной строкой через PowerCLI: у объекта кластера в API есть свойство lifecycleManaged, true означает управление образом.

Connect-VIServer vcenter.example.local
# True = кластер управляется образом vLCM, False = бейзлайны
Get-Cluster | Select-Object Name, @{N='ImageManaged';E={$_.ExtensionData.LifecycleManaged}}

Параллельно снимайте инвентарь того, что реально стоит на хостах. Это тот самый список, который потом попадёт в образ или будет удалён при remediation. Я включаю SSH на время работ и собираю три вывода с каждого хоста, затем сравниваю хосты построчно:

# на каждом хосте: версия, профиль образа и полный список VIB
esxcli system version get
esxcli software profile get
esxcli software vib list > /tmp/vib-$(hostname).txt

Разница между хостами одного кластера — это и есть ваш будущий список проблем. Каждую строку, которой нет в вендорском add-on, надо либо завести в образ компонентом, либо сознательно потерять, записав решение. Отдельно выгрузите версии BIOS и прошивок контроллеров из iDRAC или iLO: они понадобятся и для образа, и для проверки Quick Boot.

• vCenter: Cluster → Updates — блок Image вместо Baselines
• PowerCLI: свойство LifecycleManaged у кластера
• esxcli на хосте: версия, профиль и список VIB
• iDRAC/iLO: версии BIOS и прошивок

Перевод кластера на образ vLCM: порядок без простоя

Сам переход делается мастером: кластер → Updates → Image → Setup Image. Дальше образ либо собирается вручную из содержимого депо, либо импортируется с эталонного хоста, либо загружается из JSON. Импорт с хоста я предпочитаю почти всегда: vLCM вытаскивает софтверную спецификацию с реальной машины, и не надо угадывать, какие компоненты собрать. За эталон берите самый «чистый» хост — тот, который последним ставили с нуля.

Ключевая деталь для российских реалий: онлайн-синхронизация депо с серверами Broadcom доступна не всем и не всегда, а без содержимого депо мастер не покажет ни базовую версию, ни vendor add-on. Поэтому работаем офлайн-бандлами: заранее скачиваете depot-архив нужной версии ESX и add-on производителя сервера (Dell, HPE, Lenovo) и загружаете их в Lifecycle Manager через Actions → Import Updates. Именно zip-депо, а не ISO: ISO vCenter 9.0 не примет. Пока оба архива не в депо, выпадающий список версий пуст — самая частая причина жалобы «мастер образа пустой».

vCenter → Lifecycle Manager → Actions → Import Updates
  VMware-ESX-<версия>-<build>-depot.zip        # базовый образ
  <Vendor>-Addon-<версия>-depot.zip            # vendor add-on
Cluster → Updates → Image → Setup Image

Совместимость Quick Boot стоит проверить на каждом хосте заранее: от неё зависит, будет окно по 15 минут на хост или по 40. Проверка — скрипт /usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py на самом хосте. И ещё раз про необратимость: переводим по одному кластеру, начиная с наименее критичного, никогда всю ферму в одно окно. Если хотите подробнее про другие ловушки девятки — например, что после подъёма совместимости ВМ до version 22 машину уже не вернуть на резервный ESXi 8, — учтите это в плане до апгрейда.

• Снять VIB и версии прошивок со всех хостов, сравнить построчно
• Загрузить в депо zip-бандлы: базовый ESX и vendor add-on
• Подключить Hardware Support Manager, если нужны прошивки в образе
• Собрать образ импортом с эталонного хоста, добавить нужные компоненты
• Сначала образ на текущей версии 8.x — выравнивание без апгрейда
• Check Compliance: разобрать каждое расхождение до remediation
• Remediation по одному хосту, DRS в Fully Automated
• После первого хоста — проверить сеть, датасторы и пути к СХД

Где переход на образы ломается чаще всего

Первое и самое частое — пустое депо. Мастер показывает версии ESX из локального депо Lifecycle Manager. Нет бандла — нет версии в списке. Люди решают, что «vLCM не видит девятку», и ищут баг, хотя надо просто импортировать архив. Второе — прошивки. Образ умеет описывать firmware, но только если подключён Hardware Support Manager: у Dell это OpenManage Integration for VMware vCenter, у HPE — собственные интеграционные модули. Без него блок прошивок пуст, и разъезд BIOS вы разгребаете отдельно.

Третье — нештатные VIB. Всё, чего нет в образе, remediation удалит: драйвер дополнительной сетевой карты, агент мониторинга, старый multipathing-плагин. Если это нужно, заводите в образ компонентом из офлайн-бандла производителя. Если компонента в нужном формате нет, проблему надо решать до перехода. Четвёртое — Quick Boot: не функция vLCM, но именно он определяет длительность окна, а его совместимость зависит от платформы и версии BIOS.

Пятое — vSAN и NSX: у них свои предпроверки и порядок работ, переход надо согласовывать с их требованиями. Шестое — если инфраструктура под SDDC Manager (VCF), переход делается только штатными механизмами SDDC Manager, руками через vCenter туда лезть нельзя. Седьмое — поколение железа: прежде чем говорить о девятке, сверьте каждый сервер по Broadcom Compatibility Guide. После апгрейда vCenter всплывают и соседние сюрпризы — например, оставшиеся ВМ vCLS и Retreat Mode, которые тоже лучше разобрать заранее.

• Пустое депо → нет целевой версии в мастере
• Нет Hardware Support Manager → прошивки вне образа
• Нештатные VIB не заведены в образ → удалены при remediation
• Quick Boot несовместим → окно работ растёт
• vSAN/NSX → свои предпроверки и порядок
• VCF/SDDC Manager → только штатный механизм перехода
• Старое железо → сначала Broadcom Compatibility Guide

Что делать в первую очередь, а что можно отложить

Если vCenter уже 9.0, а хосты на 8.x — вы не в аварии. Патчить восьмёрку бейзлайнами можно, уязвимости закрываются. Переход на образы — задача планируемая, а не пожарная. Первое, что стоит сделать прямо сейчас, — снять инвентарь VIB и прошивок и убедиться, что вы вообще знаете, из чего состоит ваша ферма. Это бесплатно и полезно само по себе.

Если vCenter ещё на 8.x — не торопитесь его поднимать. Правильный порядок: сначала перевести кластеры на образы vLCM на восьмёрке, где у вас есть оба режима и право на ошибку, и только потом обновлять vCenter. Документация VCF прямо требует перевести кластеры на образы до апгрейда хостов на 9.0. У «Рубля к рублю» мы получили обратный сценарий по чужой вине и потратили лишние дни.

На что можно не тратить силы на первом этапе. Прошивки через vLCM приятны, но не обязательны: если парк разнородный или HSM не покрывает ваши модели, вынесите прошивки в отдельный регламент. Единый образ на все кластеры сразу — тоже не цель: сделайте по образу на кластер, унификацию оставьте на потом. И не гонитесь за девяткой ради девятки: без подписки патчей вы всё равно не получите.

Честно про 2026 год: у многих российских компаний нет активной поддержки Broadcom, и вопрос «обновляться или нет» упирается не в vLCM, а в то, откуда брать бандлы и что делать с лицензиями. Универсального ответа я не даю — это решение руководства вместе с ИТ. Но техническую часть — инвентаризацию, перевод на образы на текущей версии, проверку совместимости — стоит сделать в любом случае: она полезна и если вы останетесь на VMware, и если решите, как многие, уйти от Broadcom на Proxmox VE.

• Сейчас: инвентарь VIB и прошивок, file-based backup vCenter
• Ближайший квартал: кластеры на образы vLCM по одному, на текущей версии
• Потом: подключение HSM и прошивки из образа
• Можно отложить: единый образ на всю ферму, ESX 9 без ясности с подпиской

Частые вопросы