АйТи Фреш
Главная / Статьи / Серверы и хостинг
Серверы и хостинг

VCF 9.1 на разнородных хостах: почему установка падает и нужен ли VCF офису на 32 места

Автор: Семёнов Евгений Сергеевич, директор ООО «АйТи-Фреш» · · ~25 мин чтения
VCF 9.1 на разнородных хостах: почему установка падает и нужен ли VCF офису на 32 места
Иллюстрация к статье «VCF 9.1 на разнородных хостах: почему установка падает и нужен ли VCF офису на 32 места».

Клиент, финансовая консалтинговая компания «Разумные финансы» на 32 рабочих места, прислал ссылку на анонс VMware Cloud Foundation 9.1 с вопросом: «Там пишут, что теперь можно смешивать серверы разных вендоров. Может, переходим на VCF и заодно используем наш Dell и HPE?» Вопрос хороший, а ответ состоит из двух частей. Техническая: первичное развёртывание VCF 9.1 на хостах разных производителей не поддерживается (KB443862), а смешанное железо живёт только через composite image, который появляется после того, как vCenter уже есть. Экономическая: для офиса такого размера VCF избыточен сам по себе. Ниже — где проходит граница по вендорам, как на самом деле работает composite image, что сейчас с лицензированием после перехода Broadcom на подписку и что я в итоге предложил клиенту.

Исходные данные: три сервера, два вендора и статья про VCF 9.1

У «Разумных финансов» инфраструктура типичная для офиса на три десятка человек. Около двадцати виртуальных машин: 1С для бухгалтерии и управленческого учёта, терминальный сервер для удалённых консультантов, файловый сервер с клиентскими досье, контроллер домена, резервный контроллер, сервер резервного копирования и пара служебных ВМ. Всё это крутится на трёх хостах: два Dell PowerEdge R650, купленные вместе, и один HPE ProLiant DL360 Gen10, доставшийся от прошлого подрядчика. Гипервизор — vSphere 7 с давно закончившейся поддержкой и одним vCenter.

Директор по развитию прочитал анонс VCF 9.1 и решил, что это шанс «обновиться правильно, сразу на платформу уровня банков». Меня попросили оценить переход. Я разложил вопрос на две части: поедет ли VCF технически на этом железе и имеет ли он смысл экономически. Спойлер: по первой части «нет в том виде, в каком это задумано», по второй — «нет вообще». Но разобрать стоит подробно, потому что те же вопросы задают все, у кого в стойке серверы разных производителей.

Сначала о фактах. VMware Cloud Foundation 9.1 вышел 12 мая 2026 года — это дата в официальных release notes на techdocs.broadcom.com. Третьего сентября 2026 года Broadcom объявил 9.1.1 — первый maintenance-релиз ветки с обновлённым Bill of Materials. vSphere Foundation 9.1 выходил в той же ветке, и ограничения по вендорам, о которых дальше пойдёт речь, KB относит к обоим продуктам.

Прежде чем обсуждать платформу, выгрузите табличку «хост — вендор — модель — CPU — ядра — версия BIOS». От неё зависит и техническая совместимость, и стоимость подписки.

Ошибка, из-за которой установка VCF 9.1 не стартует

Картина всегда одинаковая. Четыре хоста под management domain стоят в стойке, ESX залит, DNS прописан прямой и обратный, NTP синхронизирован, VCF Installer поднят и ждёт. Вы жмёте валидацию — и через несколько минут получаете отказ с текстом про то, что ESX-хосты не одного вендора, и списком найденных производителей. Кнопки «продолжить всё равно» нет. Галочки «я понимаю риски» тоже нет. Развёртывание просто не начинается.

Broadcom это ограничение задокументировал в KB443862 «VVF / VCF 9.1 Installation Fails Due to Mixed-Vendor ESXi Hosts in Management Domain». Симптом — ошибка вида «vLCM is not supported on ESX Hosts with different vendor» со списком найденных производителей. Причина описана прямо: процесс развёртывания берёт первый ESX-хост как основу для образа vLCM будущего кластера, а создать composite image для разных вендоров нечем — vCenter ещё не развёрнут, сервиса vLCM нет. Курица и яйцо в чистом виде.

Это не баг конкретного билда. То же требование есть в документации по подготовке хостов для VCF и VVF 9.1: все ESX-хосты management domain должны быть от одного производителя, кросс-вендорные конфигурации в управляющем домене не поддерживаются, гетерогенные конфигурации кластера при первичном развёртывании управляющего домена не поддерживаются. Resolution в KB соответствующий: привести начальный кластер к одному вендору, переустановить ESX и запустить развёртывание заново.

Хорошая новость в том, что падение происходит на валидации, до того как хоть что-то развернулось. Ничего откатывать не нужно, данные не теряются, хосты остаются в том же состоянии. Плохая новость — переигрывать приходится план, а не конфиг.

Инвентаризацию вендора и модели делайте ДО закупки лицензий и до бронирования окна. Один запуск esxcli на четырёх хостах экономит перенесённые выходные.
VCF 9.1 на разнородных хостах: почему установка падает и нужен ли VCF офису на 32 места — схема
Схема к статье. Открыть схему в полном размере

Composite image умеет ровно то, что обещано, но начиная со дня N+1

Откуда взялось заблуждение — понятно. В vSphere 9 действительно появились составные образы кластера: один composite image содержит базовый образ по умолчанию и дополнительные определения, до четырёх штук. Базовая версия ESX для всех определений общая и не редактируется — это принципиально. А вот vendor add-on, firmware add-on и набор компонентов у каждого определения свои, и к каждому определению можно привязать собственный hardware support manager.

Раздача образов по хостам делается двумя способами: вручную указать подмножество хостов, либо автоматически — по данным System BIOS: Vendor, Model, OEM String, Family. Канонический пример из документации: в кластере пять хостов Dell и пять HPE, Dell-хостам назначается определение с Dell vendor add-on и Dell HSM, HPE-хостам — своё, с HPE add-on и своим HSM. Один кластер, один жизненный цикл, разное железо. Ровно то, чего от платформы годами ждали.

По документации Broadcom для VCF 9.x кластер может иметь до четырёх дополнительных определений образа в составе одного composite image. Базовая версия ESX для всех дополнительных образов статична и не настраивается, а vendor add-on, firmware и компоненты каждого определения можно настроить под смешанное железо. На практике закладывайтесь на два-три профиля железа в кластере: если их пять, вы уже строите зоопарк, который потом придётся обслуживать руками.

И главное. Composite image — объект vCenter. Он создаётся в vSphere Client и затем импортируется в экземпляр VCF (в документации 9.x — через VCF Operations, в KB443862 упоминается SDDC Manager). VCF Installer его не собирает. Для небольшой компании отсюда важный вывод: смешанный кластер через composite image — возможность vSphere 9 и vLCM, а не эксклюзив VCF. Если у вас уже есть vCenter 9, образ со вторым определением под другого вендора собирается и в обычном кластере vSphere Foundation.

Правило, которое я держу в голове: composite image — инструмент дня N+1. На день ноль у вас его нет и взять неоткуда.

Почему VCF для офиса на 32 места избыточен

Даже если бы вендорной проблемы не было, VCF — это частное облако целиком: management domain со своим vCenter, NSX, VCF Operations и сопутствующими компонентами, отдельные workload domain под бизнес-нагрузку, автоматизация жизненного цикла всего стека. Одни только управляющие компоненты съедают заметную часть ресурсов, и проектируется это под десятки и сотни хостов. У «Разумных финансов» три сервера и двадцать ВМ — управляющий слой занял бы ресурсов сопоставимо с самой бизнес-нагрузкой.

Второй аргумент — лицензирование. После покупки VMware Broadcom отказался от бессрочных лицензий и перешёл на подписку с метрикой «ядро». Официальное правило из KB о подсчёте ядер: лицензируются все физические ядра хостов, минимум 16 ядер на каждый процессор, даже если ядер меньше. VCF даёт 1 TiB ёмкости vSAN на каждое купленное ядро, VVF — 0,25 TiB на ядро. Для трёх двухсокетных хостов это минимум 96 ядер подписки при любом выборе редакции, а цена ядра у VCF заметно выше, чем у VVF или vSphere Standard.

Отдельно про «72 ядра». Весной 2025 года дистрибьюторы сообщали о переходе на минимальный заказ в 72 ядра с 10 апреля 2025, и эта цифра до сих пор гуляет по статьям. По сообщениям тех же каналов и профильной прессы, Broadcom от этого правила отказался, а в KB о подсчёте ядер минимум на заказ не фигурирует — там только 16 ядер на процессор. Если в коммерческом предложении вам выставляют порог выше, требуйте письменного обоснования: это условие конкретной сделки, а не опубликованное правило.

Для малого бизнеса у Broadcom остались младшие продукты. В актуальной программной документации (SPD) от февраля 2026 года описан vSphere Essentials Plus — подписка по ядрам с минимумом 16 ядер на процессор, продаётся пакетом на 96 ядер. Условия доступности зависят от региона и партнёра. И честная оговорка для российских юрлиц: VMware приостановил работу в России в 2022 году, официальная покупка подписки и поддержка напрямую недоступны, а без подписки нет ни обновлений, ни доступа к депоту. Это аргумент, который для «Разумных финансов» перевесил всё остальное.

Не покупайте платформу под новость о новой функции. Сначала посчитайте ядра, ёмкость хранилища и реальную потребность в компонентах стека — для офиса до 50 мест VCF почти никогда не окупается.
Цифры и версии: Почему VCF для офиса на 32 места избыточен — схема
Цифры и версии: Почему VCF для офиса на 32 места избыточен. Открыть схему в полном размере

Разбор из практики: что мы предложили «Разумным финансам»

Сначала я показал клиенту, что было бы с VCF в лоб. Два Dell и один HPE в одном management domain — это ровно сценарий из KB443862: инсталлятор остановится на валидации. Даже если убрать HPE, двух одинаковых Dell для управляющего домена под vSAN недостаточно, а вся бизнес-нагрузка всё равно должна где-то жить. То есть пришлось бы докупать минимум два-три сервера одной модели только ради того, чтобы разместить управляющий слой. На слайде «платформа уровня банков» выглядела солидно, в смете — абсурдно.

Потом разобрали, что клиенту на самом деле нужно: живая миграция ВМ при обслуживании хоста, перезапуск ВМ при отказе сервера, резервное копирование с понятным восстановлением и предсказуемые обновления. Всё это закрывает обычный кластер из трёх хостов с общим хранилищем и одним менеджером. Никакой микросегментации NSX, мультитенантности и автоматизации частного облака бухгалтерии и терминальному серверу не требуется.

Итоговый выбор определили не технические, а юридические условия: легальной подписки на vSphere у российского юрлица сейчас нет, а сидеть на vSphere 7 без патчей с клиентскими финансовыми данными мы не готовы. Мигрировали на кластер Proxmox VE из тех же трёх серверов: смешение Dell и HPE для него не проблема, живая миграция и HA есть, резервное копирование — Proxmox Backup Server на отдельном хосте. Миграция двадцати ВМ заняла два вечера с поочерёдным переносом, 1С и терминальный сервер переносили в выходные.

Если бы клиент работал в юрисдикции, где подписка доступна, я бы предложил vSphere Foundation или Essentials Plus на трёх хостах и vCenter 9, а разнородность железа закрыл бы composite image с двумя определениями: Dell add-on с Dell HSM и HPE add-on с HPE HSM. Это штатный сценарий vLCM, и управляющий домен VCF для него не нужен.

Главный риск такой миграции — не гипервизор, а резервное копирование и лицензии прикладного ПО. Проверьте восстановление 1С и привязку лицензий к оборудованию до переноса, а не после.

Сценарии, когда железо уже разное

Первый сценарий для крупного проекта на VCF: отобрать однородную группу хостов под management domain, всё остальное отправить в workload domain через composite image. Скучно, зато поддерживается и документировано. Критерий отбора не «самые мощные», а «самые одинаковые»: одна модель, одна версия BIOS, одна версия ESX.

Второй — путь converge: VCF Installer 9.x умеет забирать существующую инфраструктуру vSphere и превращать её в management domain. У этого пути свой список поддерживаемых и неподдерживаемых конфигураций — в частности, кластеры должны управляться образами vLCM, а не baselines, есть требования к DRS и распределённому коммутатору, не поддерживаются Enhanced Linked Mode и vCenter HA. В документации по converge я не нашёл явного разрешения смешанного вендора для управляющего кластера, а требование единого производителя в доке по подготовке хостов сформулировано без оговорок. Если сценарий критичен — открывайте кейс в поддержке Broadcom с перечнем моделей до закупки.

Третий — сценарий малого офиса без VCF: vSphere Foundation, vSphere Standard или Essentials Plus с одним vCenter 9. Разнородность закрывается composite image прямо в кластере, никакого первичного развёртывания management domain нет, значит нет и ограничения KB443862. Если определения образа кажутся избыточными, можно развести вендоров по двум отдельным кластерам со своими образами — ценой меньшей гибкости при миграции ВМ.

Четвёртый — альтернативные гипервизоры, когда подписка недоступна или неоправданно дорога: Proxmox VE, Hyper-V в составе Windows Server, отечественные платформы виртуализации из реестра российского ПО. Для них разнородное железо в кластере — обычная ситуация, важны только совместимые CPU для живой миграции и поддержка контроллеров и сетевых карт. Пятый вариант — подмена SMBIOS — существует, но только для лаборатории, о нём ниже.

Не тратьте время на попытки обмануть валидацию пересборкой ISO. Проверка смотрит в железо, а не в образ, — это тупик, который в среднем съедает пол-дня.

Лабораторный обход: подмена SMBIOS и почему он не для продакшена

Обход существует, его описал Уильям Лэм ещё для VCF 9.0, и логика проверки в 9.1 та же, что описана в KB443862. Идея: заставить «чужой» хост представляться тем же производителем, что и эталонный. Сначала на эталонном хосте снимаются реальные значения DMI, потом на подопытном в kernelopt добавляется параметр ignoreHwSMBIOSInfo=TRUE, и после перезагрузки значения подменяются командой vsish.

Практическая последовательность выглядит так.

# 1) на эталонном хосте снять реальные значения DMI
vsish -e get /hardware/bios/dmiInfo

# 2) на подменяемом хосте: в /bootbank/boot.cfg
#    к строке kernelopt дописать ignoreHwSMBIOSInfo=TRUE
#    затем перезагрузить
reboot

# 3) после загрузки выставить снятые значения
vsish -e set /hardware/bios/dmiInfo <значения с эталонного хоста>

Для домашней лаборатории и демо-стенда — рабочий трюк: так можно показать интерфейс VCF на том, что было под рукой. Для боевого управляющего домена — категорическое нет, и уж тем более не для небольшой компании, где никто не будет вручную повторять процедуру после каждого ребута: «потом переделаем» в инфраструктуре наступает через три года.

Для домашней лаборатории и для демо-стенда — отличный трюк, я им пользовался, чтобы показать заказчику интерфейс VCF на том, что было под рукой. Для боевого управляющего домена — категорическое нет, и я бы не советовал даже «временно, а потом переделаем»: «потом» в инфраструктуре наступает через три года.

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

Как собрать composite image и завести его в VCF правильно

Порядок действий, который работает без сюрпризов. Composite image создаётся в vSphere Client уже развёрнутого vCenter: в VCF — это vCenter управляющего домена, в обычной vSphere 9 — vCenter вашего кластера. Сначала задаётся базовая часть: версия ESX. Затем добавляются дополнительные определения, в каждом указывается свой vendor add-on, набор компонентов, при необходимости firmware и привязка к hardware support manager вендора. Дальше настраиваются правила назначения — вручную по списку хостов либо автоматически по System BIOS. В VCF после этого образ импортируется в экземпляр и становится доступен при создании нового workload domain или добавлении кластера.

Самая частая причина «образ не собирается» — вовсе не архитектурные ограничения, а пустой или неполный депот. В изолированных контурах компоненты и vendor add-on надо предварительно вытянуть VCF Download Tool и положить в offline depot, иначе в выпадающих списках вы просто не увидите нужного add-on и будете думать, что платформа его не поддерживает. Проверяйте наполнение депота до того, как садиться собирать образ.

Про firmware дам непопулярный совет: на первом внедрении не тащите firmware add-on в образ вообще. Пусть сначала заработает софтовая часть — базовый ESX, драйверы, vendor add-on. Firmware-часть требует зарегистрированного HSM, у HSM свои версии, свои плагины и своя манера отваливаться в самый неподходящий момент. Добавите вторым заходом, когда кластер уже живой и есть окно на эксперименты.

И перед созданием домена обязательно прогоните проверку соответствия на одном хосте каждого типа железа. Compliance-проверка на пустом хосте занимает минуты, а ловит и неверный фильтр назначения, и отсутствующий компонент, и несовпадение базовой версии. Гораздо приятнее увидеть это в vSphere Client, чем на середине развёртывания домена.

Пустой депот выглядит как «платформа не поддерживает моё железо». Сначала проверьте, что компоненты вендора вообще доехали.
Порядок действий: Как собрать composite image и завести его в VCF правильно — схема
Порядок действий: Как собрать composite image и завести его в VCF правильно. Открыть схему в полном размере

Чек-лист перед окном внедрения

Я делаю одну простую вещь до того, как первый раз запущу VCF Installer: собираю табличку «хост — вендор — модель — версия BIOS — версия ESX — билд». Пять минут работы, и половина потенциальных сюрпризов видна сразу. Команды, которые дают всё нужное.

for h in esx01 esx02 esx03 esx04; do
  printf '== %s\n' "$h"
  ssh root@"$h" 'esxcli hardware platform get'
  ssh root@"$h" 'esxcli system version get'
done

Дальше по списку идут вещи, которые ломают развёртывание не реже, чем вендорность, но обсуждаются почему-то реже. Несовпадение FQDN хоста с subject alternative name в его сертификате — отдельная популярная ошибка на этапе commissioning, лечится перегенерацией самоподписанного сертификата после того, как имя и DNS приведены в порядок. Расхождение времени между хостами и инсталлятором. Забытый stateless-хост в списке. Кластеры под baselines вместо образов, если идёте путём converge.

И финальное, организационное. Согласуйте состав кластера и выбор платформы письменно до того, как железо разъедется по ролям и до оплаты подписки. Ограничение VCF 9.1 неприятно не тем, что оно сложное, а тем, что о нём узнают в последний момент — когда лицензии куплены и окно на выходные согласовано.

Если управляющий домен уже спроектирован как «по два хоста каждого вендора ради надёжности» — переделывайте проект сейчас, а не на валидации.

Моя оценка: где риск реальный, а где раздутый

Ограничение выглядит обидно, но бьёт оно ровно по одному сценарию — первичное развёртывание нового management domain на разнородном парке. Всё остальное закрыто: новые workload domain, добавляемые кластеры, расширение существующих, смешение поколений и моделей одного вендора. То есть 90 % реальной жизни VCF смешанное железо переваривает штатно, через composite image.

Поэтому первое, что я говорю клиентам: «нам теперь нельзя смешивать железо» — неправда. Нельзя смешивать в первом кластере management domain при развёртывании VCF или VVF 9.1. «Нам нужен VCF, чтобы смешивать железо» — тоже неправда: composite image — функция vLCM в vSphere 9, и в обычном кластере с vCenter она доступна без управляющего домена.

Где риск настоящий — это планирование и brownfield. Планирование: если архитектор нарисовал разнородный управляющий домен, вы узнаете об этом на валидации, за сутки до окна, когда лицензии куплены и люди выведены на работу в выходные. Brownfield: если у вас сотня хостов на vSphere 8 со смешанными кластерами, там один desired image на кластер, composite image недоступен до перехода на 9.x, и последовательность «импортировать как есть, поднять vCenter до 9.x, собрать composite image, потом обновлять ESX» выглядит логично, но официального подтверждения я не нашёл. Соответствующий вопрос на форуме Broadcom висит без ответа. Это ровно тот случай, когда единого мнения нет, и решать надо через официальный кейс в поддержке, а не по блогам.

Приоритеты для небольшой компании, если коротко. Первым делом — инвентаризация железа и подсчёт ядер. Вторым — честный ответ, нужен ли вам стек частного облака или достаточно кластера из трёх хостов с HA и резервным копированием. Третьим — проверка, можете ли вы легально купить и продлевать подписку. Для «Разумных финансов» эти три шага заняли одну встречу и сэкономили бюджет на серверы, которые понадобились бы только управляющему слою VCF.

Практический вывод одной строкой: VCF — для крупных парков с однородным management domain; офису на 30–50 мест хватит кластера из трёх хостов, а разнородное железо решается composite image или другим гипервизором.
Цифры и версии: Моя оценка: где риск реальный, а где раздутый — схема
Цифры и версии: Моя оценка: где риск реальный, а где раздутый. Открыть схему в полном размере

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

Можно ли вообще смешивать хосты разных вендоров в VCF 9.1?

Да, но не в первом кластере при развёртывании. Первичное развёртывание management domain VCF или VVF 9.1 на хостах разных производителей не поддерживается (KB443862). Для новых workload domain и добавляемых кластеров смешанное железо поддерживается через composite image, который собирается в vCenter и импортируется в VCF.

Поможет ли custom ISO, куда включены add-on обоих вендоров?

Нет. Валидация читает данные SMBIOS/DMI самого сервера, а не содержимое установочного образа. Стоковый ESX без вендорских add-on тоже не помогает по той же причине: производитель приезжает из железа.

Сколько разных типов железа помещается в один кластер vSphere 9?

По документации Broadcom для VCF 9.x кластер может иметь до четырёх дополнительных определений образа в одном composite image. Базовая версия ESX общая и не настраивается; различаться могут vendor add-on, компоненты, firmware и привязанный hardware support manager.

Можно ли добавить хост другого вендора в management domain после того, как он развёрнут?

Технически кластером уже управляет vCenter, и composite image становится доступен. Но требование о едином производителе для management domain в документации по подготовке хостов сформулировано без оговорок про этап, поэтому вопрос спорный: перед таким шагом стоит получить письменное подтверждение поддержки Broadcom под ваши конкретные модели.

Нужен ли VCF компании на 30–50 рабочих мест?

Почти никогда. VCF — стек частного облака с управляющим доменом, NSX и VCF Operations, рассчитанный на крупные парки. Офису с тремя-четырьмя серверами хватает кластера с HA и живой миграцией: vSphere Foundation, Standard или Essentials Plus, а если подписка недоступна — Proxmox VE или Hyper-V.

Сколько ядер придётся покупать и правда ли, что минимум 72?

По KB Broadcom о подсчёте ядер лицензируются все физические ядра, минимум 16 на каждый процессор — для трёх двухсокетных хостов это не меньше 96 ядер. Минимальный заказ в 72 ядра анонсировали дистрибьюторы весной 2025 года, но, по сообщениям отрасли, Broadcom его отменил, и в KB такого порога нет. Если его ставят в коммерческом предложении, требуйте письменного обоснования.

Можно ли собрать смешанный кластер Dell + HPE без VCF?

Да. Composite image — возможность vLCM в vSphere 9: в vCenter создаётся образ с базовой версией ESX и дополнительным определением под второго вендора, хосты назначаются по System BIOS. Ограничение KB443862 касается только первичного развёртывания management domain VCF/VVF, где vCenter ещё нет.

Что делать с brownfield-парком на vSphere 8, где кластеры уже смешанные?

В vSphere 8 на кластер приходится один desired image, поэтому composite image там недоступен. Логичная последовательность — импортировать как есть, поднять vCenter до 9.x, собрать composite image и только потом обновлять ESX. Официального подтверждения такой схемы я не нашёл, аналогичный вопрос на форуме Broadcom остался без ответа, так что для крупного парка это тема для официального кейса в поддержке.

Обход через подмену SMBIOS годится для боевой инсталляции?

Нет. Значения, выставленные через vsish, не сохраняются после перезагрузки, ломается логика hardware support manager и подбор firmware, конфигурация не поддерживается вендором. Это приём для лаборатории и демо-стенда, не для продакшена.

Столкнулись с похожей задачей? Обращайтесь — решим

Если у вас происходит что-то из описанного в этой статье — или любая другая проблема с ИТ-инфраструктурой, — обращайтесь в любое время. Мои специалисты и я лично разберём ситуацию, найдём настоящую причину и доведём до решения.

Возьмёмся и за разовую задачу, и за постоянное обслуживание. Первичная консультация — бесплатно и без обязательств.

📞 +7 903 729-62-41 💬 MAX: +7 903 729-62-41 ✈ Telegram @ITfresh_Boss

С уважением, Семёнов Евгений Сергеевич, директор «АйТи Фреш» — IT-аутсорсинг для компаний до 50 рабочих мест, 15+ лет практики

Источники

© ООО «АйТи-Фреш» · Москва · Все статьи