VMware ESXi все версии: сравнение возможностей и требований

Вопрос «какой гипервизор выбрать» для многих команд стал не абстрактным — а вполне конкретным. И ответ начинается с понимания, как ESXi менялся от версии к версии.

Давайте разложим всё по полочкам: от первого ESX 1.0 до ESXi 8.0 — что росло, что отпиливали и зачем. Спойлер: за 20 с лишним лет гипервизор прошёл путь от «запускает пару VM на одном сервере» до «оркестрирует тысячи контейнеров и работает на ARM».

Хронология: от ESX к ESXi

VMware ESXi прошёл путь длиной в два десятилетия. Первый ESX 1.0 появился в 2001 году — тогда это был просто bare-metal гипервизор с поддержкой гостевых Windows и Linux. Ни vMotion, ни кластеров, ни даже нормальной консоли управления. Просто виртуальные машины на голом железе. Зато сама идея — запустить несколько ОС на одном физическом сервере без промежуточной операционной системы — была революционной.

Цикл поддержки здесь показателен: VMware даёт 5 лет General Support и ещё 2 года Technical Guidance (без патчей безопасности). ESXi 7.0 вышел из General Support в октябре 2025, а Technical Guidance закончится в октябре 2027. Для ESXi 8.0 — 2027 и 2029 соответственно.

Архитектурная эволюция: зачем убили Service Console

До версии 4.1 ESX работал с полноценной Service Console — по сути, это был урезанный Linux (Red Hat-based), через который шло управление хостом. Удобно? Безусловно. Безопасно? Не особенно. Каждый лишний компонент — это дополнительная поверхность атаки, лишние обновления, лишние ресурсы.

ESXi 4.1 в 2010 году полностью убрал Service Console. Размер установочного образа упал до ~150 МБ, потребление ресурсов самим гипервизором сократилось, а количество потенциальных уязвимостей уменьшилось. С версии 5.0 (2011) ESX окончательно ушёл со сцены — остался только ESXi. Никакого параллельного существования двух веток.

Это была не просто косметическая доработка. Переход на «тонкий» гипервизор без Service Console — одна из причин, почему VMware ESXi до сих пор остаётся стандартом для enterprise-виртуализации. Меньше кода — меньше багов — быстрее загрузка. Для сравнения: полный ESX с консолью загружался минуты, ESXi мог стартовать за 60-90 секунд. А с появлением Quick Boot в поздних версиях — перезагрузка гипервизора (без POST) стала занимать считанные секунды.

Параллельно росли требования к безопасности. ESXi 6.5 принёс шифрование VM и Encrypted vMotion. ESXi 7.0 добавил поддержку TPM 2.0 для Secure Boot, а ESXi 8.0 усилил защиту через поддержку DPU — отдельных процессорных модулей на сетевых картах, которые берут на себя обработку безопасности и сетевых функций, снимая нагрузку с основного CPU хоста.

Лимиты ресурсов: как ESXi рос вместе с железом

Вот где VMware ESXi показывает рост наглядно. Цифры в таблице ниже — это рекомендованные максимумы, протестированные и поддерживаемые вендором.

Рост с 64 логических CPU на хост (ESXi 4.0) до 960 (ESXi 8.0 U2) — это не просто «стало больше». Это отражение того, как серверное железо ушло от двухсокетных систем с 4-ядерными процессорами к монстрам на 128-ядерных AMD EPYC. Гипервизор должен был научиться работать с этими масштабами.

Ещё один показательный прыжок — vCPU на одну виртуальную машину. В ESXi 4.0 лимит был 8 (что сегодня кажется смешным), а в ESXi 7.0 U1 с виртуальным оборудованием 18-й версии — уже 768. Для задач вроде SAP HANA или крупных баз данных в единственной VM это критично.

Отдельно про vHardware (Virtual Hardware Version). Каждая версия ESXi привносит новую версию виртуального оборудования, которая определяет, какие возможности доступны виртуальной машине. ESXi 6.7 — vHardware 14, ESXi 7.0 — 19, ESXi 8.0 — 20. Совместимость обратная: VM с vHardware 14 запустится на ESXi 8.0, но не наоборот. Это нужно учитывать, если Вы планируете миграцию между кластерами разных версий.

Ключевые фичи: что появлялось от версии к версии

Таблица лимитов показывает масштаб, но не функциональность. А ведь ESXi обрастал возможностями с каждым релизом.

vMotion (ESX 3.0, 2006) — технология, которая сделала VMware тем, чем он стал. Перенос работающей VM между хостами без простоя. До этого «живая миграция» была из области фантастики.

VAAI — vStorage APIs for Array Integration (ESXi 5.0, 2011) — разгрузка операций хранения с гипервизора на СХД. Клонирование VM стало в разы быстрее, потому что копирование данных происходит на стороне массива, а не через хост.

Virtual Volumes (ESXi 6.0, 2015) — новый подход к хранилищу, где каждая VM получает собственный объект на уровне массива. Гранулярнее управление, индивидуальные политики хранения.

Encrypted vMotion (ESXi 6.5, 2016) — шифрование трафика при миграции VM. В эпоху compliance-требований и GDPR — не просто «nice to have».

Tanzu и Kubernetes (ESXi 7.0, 2020) — нативная интеграция контейнерного оркестратора прямо в vSphere. Это не просто «можно запустить K8s в VM» — это Supervisor Cluster, встроенный в гипервизор, который управляет пространствами имён Kubernetes так же, как vCenter управляет виртуальными машинами. Плюс поддержка процессоров ARM, что расширило гипервизор за пределы классической x86-архитектуры.

DPU и Quick Boot (ESXi 8.0, 2022) — поддержка Data Processing Units (SmartNIC нового поколения), разгружающих сетевые и безопасные операции с основного CPU. По сути, DPU — это отдельный компьютер на Вашей сетевой карте с собственным процессором и памятью, который обрабатывает файервол, шифрование трафика и микросегментацию NSX, не отнимая ядра у рабочих нагрузок. Quick Boot позволяет перезагрузить гипервизор за секунды, пропуская POST — неоценимо при накатывании патчей на хосты в продакшене.

Аппаратные требования: что нужно железу

Каждая новая версия ESXi поднимала планку для оборудования. И если раньше это было «нужно чуть больше RAM», то в 8.0 изменения стали принципиальными.

Главный сюрприз ESXi 8.0 — жёсткие требования к CPU. Процессоры старше Intel Skylake или AMD EPYC первого поколения (Naples) инсталлятор просто не примет. Для организаций с парком серверов 5-7-летней давности это может означать замену железа, а не просто обновление софта. Сервер на Intel Broadwell или Haswell, который исправно работал под ESXi 6.7, для восьмой версии уже не подходит — и никакие хаки с allowLegacyCPU не спасут в продакшене (хотя для лаборатории этот флаг пока работает).

Ещё один нюанс: ESXi 8.0 — последняя версия, позволяющая установку на USB-флешки и SD-карты. VMware и раньше это не рекомендовала, но теперь официально закрывает эту тему. Загрузочный диск — SSD или NVMe от 32 ГБ, с рекомендуемыми 128 ГБ и скоростью записи от 100 МБ/с. Причина проста: гипервизор активно пишет логи, crash-дампы и файлы подкачки в ESX-OSData volume. Низкоресурсные USB-носители не выдерживают такой нагрузки и деградируют за считанные месяцы.

Лицензирование: что натворил Broadcom

Эта тема заслуживает отдельной статьи (и, возможно, отдельного антидепрессанта), но кратко: после поглощения VMware компанией Broadcom в ноябре 2023 года мир лицензирования перевернулся.

Perpetual-лицензии (бессрочные) больше не продаются. Точка. Все новые покупки — только подписка. Broadcom свернул ~168 отдельных SKU в четыре бандла: VMware Cloud Foundation (VCF), vSphere Foundation (VVF), vSphere Standard (VVS) и vSphere Essentials Plus Kit (VVEP). Отдельные продукты вроде vSAN или NSX как самостоятельные SKU прекратили существование — теперь они идут только в составе бандлов.

Лицензирование перешло на модель «по ядрам» с минимумом покупки — 72 ядра (до апреля 2025 минимум был 16). Если у Вас сервер с 8 ядрами, Вы всё равно платите за 72. Два сервера по 16 ядер? Те же 72 ядра минимум на каждый.

Для крупных компаний это болезненно, но терпимо. Для среднего и малого бизнеса — катастрофа. Рост расходов на лицензирование в 3-5 раз — типичная история. Есть случаи, когда стоимость подписки увеличилась на 500% и выше.

Бесплатная версия ESXi Hypervisor тоже пережила драму: в феврале 2024 Broadcom объявил о прекращении её распространения, но в апреле 2025 вернул Free ESXi 8.0 Update 3e в виде отдельного ISO-образа со встроенным лицензионным ключом. Ограничения прежние — до 8 vCPU на VM, без vCenter API, без коммерческой поддержки. Для тестовых лабораторий и домашних стендов — работает. Для прода — нет.

Ещё один неприятный момент: штраф 20% от стоимости первого года подписки за просрочку продления. Забыли продлить в срок — платите больше. Broadcom активно проводит аудиты лицензий, и с переходом на подписочную модель контроль за потреблением стал жёстче. Телеметрия в vSphere+ включена по умолчанию, и VMware видит, сколько ядер Вы реально используете.

Миграция: грабли, о которых не пишут в Release Notes

Обновление между версиями ESXi — не просто «вставил ISO — нажал Next». Вот несколько вещей, которые стоит знать.

Начиная с ESXi 7.0, схема разделов загрузочного диска изменилась радикально. Вместо отдельных разделов core dump, locker и scratch теперь используется единый ESX-OSData volume на базе VMFS-L. При обновлении с 6.x на 7.0+ диск переразбивается автоматически. Это означает одну неприятную вещь: откатиться обратно на 6.x без полного восстановления из бэкапа нельзя. Между 8.x и 7.x откат возможен — но только если не изменялись bootbank-разделы.

Совместимость оборудования — второй подводный камень. VMware ведёт HCL (Hardware Compatibility List), и каждая новая версия ESXi может исключить поддержку старых контроллеров, сетевых карт и процессоров. Перед обновлением проверяйте HCL. Не «наверное проверю» — а реально проверяйте, иначе рискуете получить неподдерживаемую конфигурацию, на которую VMware не примет тикет.

Порядок обновления: сначала vCenter, потом хосты ESXi. Никогда наоборот. vCenter 8.0 умеет управлять хостами 7.0 и 8.0 внутри одного кластера — это позволяет обновлять инфраструктуру поэтапно.

И ещё одна деталь: в ESXi 8.0 больше нельзя использовать программные адаптеры FCoE (Fibre Channel over Ethernet) — только аппаратные. Если у Вас software FCoE — это повод остановиться и подумать перед апгрейдом.

Про сетевые драйверы отдельная история. В ESXi 8.0 наконец-то включили Community Networking Driver прямо в дистрибутив. Раньше для популярных сетевых карт Intel (e1000, I220, I225, I226) приходилось вручную собирать кастомный ISO с VIB-модулем от VMware Flings. Теперь для лабораторных и тестовых окружений жизнь стала проще — драйвер идёт из коробки, хотя для продакшена VMware по-прежнему рекомендует карты из HCL.

Какой гипервизор выбрать: ESXi и рынок сегодня

Вопрос «какой гипервизор выбрать» перестал иметь один очевидный ответ. Пять лет назад VMware ESXi был безальтернативным стандартом для enterprise. Сегодня после действий Broadcom — это зависит от масштаба, бюджета и готовности к переменам.

Для крупных enterprise-инсталляций с существующими инвестициями в vSphere-экосистему, ESXi 8.0 по-прежнему мощнейший гипервизор с лимитами, которые закрывают любые задачи: 960 логических CPU на хост, 24 ТБ RAM, 768 vCPU на VM, нативный Kubernetes, поддержка DPU. Экосистема вокруг vSphere (vSAN, NSX, Aria) создаёт интеграционный эффект, который трудно воспроизвести на альтернативных платформах.

Для среднего бизнеса и новых инсталляций выбор уже не так однозначен. Proxmox VE, XCP-ng, Microsoft Hyper-V — все эти платформы активно набирают пользователей, которых вытолкнули новые ценники Broadcom. Proxmox, к примеру, строится на KVM и LXC, предлагает веб-интерфейс управления и не требует подписки для работы. Hyper-V интегрирован в Windows Server и может быть интересен тем, кто уже живёт в Microsoft-стеке.

А если Вы только начинаете строить виртуализованную инфраструктуру — не поленитесь посчитать TCO на 3-5 лет вперёд. Стоимость железа часто бледнеет на фоне стоимости лицензий. Двухсокетный сервер обойдётся в 500-800 тысяч рублей, а подписка VMware на его ядра за три года может стоить столько же — или больше.

ESXi прошёл путь от экспериментального гипервизора 2001 года до фундамента, на котором работают миллионы VM по всему миру. Двадцать лет эволюции — от 64 CPU на хост до 960, от Service Console до DPU-оффлоада, от бессрочных лицензий до подписок с минимумом в 72 ядра. Куда пойдёт эта дорога после Broadcom — покажут ближайшие пару лет. Пока что ESXi остаётся тем гипервизором, с которым сравнивают остальных. Вопрос лишь в том, сколько это будет стоить.