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

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

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

Хронология: от 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 соответственно.

Почему ESXi снова стал ESX

Деталь, которая сбивает с толку при поиске документации. Начиная с vSphere 9 продукт официально называется VMware ESX - без буквы «i» на конце. Broadcom вернул историческое имя, которое использовалось до 2007 года.

На практике это значит вот что. Ищете вы «ESXi 9» - и получаете разнобой: половина источников пишет по-старому, половина по-новому, официальные релиз-ноты Broadcom озаглавлены «VMware ESX 9.0». Продукт при этом тот же самый: это прямое продолжение линейки ESXi 8.0, а не отдельная ветка. Просто имя вернули к исходному.

Ещё один сдвиг: vSphere 9 распространяется в составе VMware Cloud Foundation 9.0. Отдельным продуктом, который покупают и обновляют сам по себе, гипервизор быть перестал - он часть платформы.

Архитектурная эволюция: зачем убили 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 хоста. В девятой ветке этот вектор довели до логичного конца: vCenter, ESX и NSX по умолчанию работают в режиме, соответствующем криптографическим стандартам FIPS 140-2 и 140-3 - раньше это включалось отдельно.

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

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

Девятой ветки в этой таблице намеренно нет, и вот почему. Broadcom перестал публиковать конфигурационные максимумы статичным списком - теперь это онлайн-инструмент Configuration Maximums, где значения фильтруются по версии и продукту и правятся между апдейтами. Замораживать их в статье бессмысленно: цифра, актуальная сегодня, разъедется с реальностью через полгода. Если планируете инфраструктуру под ESX 9, сверяйтесь с этим инструментом на дату проекта, а не с любой статьёй, включая эту.

Рост с 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 7.0 при выходе было vHardware 17, к 7.0 U2 - уже 19. У ESXi 6.7 - 14, у 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 - неоценимо при накатывании патчей на хосты в продакшене.

Memory Tiering и ускорение GPU (ESX 9.0, 2025) - главное практическое приобретение девятой ветки. Memory Tiering вышел из статуса технологического превью: NVMe-накопитель, установленный локально в хост, подключается как дополнительный «медленный» уровень оперативной памяти. Гипервизор сам решает, какие страницы держать в DRAM, а какие вытеснить на NVMe. Смысл прямой: под нагрузки, которым нужен объём, а не задержка, память наращивается заметно дешевле, чем планками DRAM.

Второе - работа с виртуальными GPU. Операция быстрого приостановления и возобновления виртуальной машины с vGPU ускорилась радикально: на паре карт L40 то, что занимало около 42 секунд, стало занимать около двух. Передача данных vGPU разложена на несколько параллельных TCP-соединений, и пропускная способность выросла с 10 до 30 Гбит/с. Для инфраструктуры под ИИ и рендеринг это разница между «миграция GPU-машины - это простой» и «миграция GPU-машины - рутинная операция».

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

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

Отдельно стоит сказать про подбор железа под платформу целиком, а не только под гипервизор: у нас есть полное руководство по выбору сервера под VMware vSphere.

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

В девятой ветке Broadcom перестал называть минимальное поколение процессора прямо в требованиях, отправляя к Compatibility Guide. На практике это не послабление, а наоборот: список поддерживаемого железа сузился, и проверять свою конкретную модель нужно обязательно до, а не после закупки лицензий.

Ещё один нюанс: ESXi 8.0 - последняя версия, позволяющая установку на USB-флешки и SD-карты. VMware и раньше это не рекомендовала, но теперь официально закрывает эту тему. Загрузочный диск - SSD или NVMe от 32 ГБ, с рекомендуемыми 128 ГБ. В требованиях девятой ветки появилась и цифра по ресурсу: носитель должен выдерживать не менее 128 TBW, и желателен RAID 1. Причина проста: гипервизор активно пишет логи, 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 видит, сколько ядер вы реально используете.

Что делать российским командам

Отдельный разговор, потому что для российской инфраструктуры вопрос звучит иначе, чем в остальном мире. VMware свернула работу в России, официальных продаж и поддержки нет, обновления через прямые каналы недоступны. Существующие инсталляции при этом никуда не делись - в стране крутятся тысячи хостов ESXi, и их администраторы каждый день решают одну из трёх задач.

Первая - жить на том, что есть. Гипервизор работает и без подписки; проблема не в том, что он остановится, а в том, что перестают приходить патчи безопасности. Для контура, отрезанного от интернета, это терпимо на горизонте пары лет. Для инфраструктуры с внешними сервисами - риск накапливается, и его надо считать явно, а не откладывать.

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

Третья - переезжать. Именно этот сценарий за последние годы стал массовым. Основные направления - Proxmox VE, российские платформы виртуализации из реестра, KVM «руками» для команд с сильной Linux-экспертизой. Переезд стоит времени и денег, но у него хотя бы предсказуемый конец, в отличие от бесконечного откладывания.

Общий совет один, и он не про технологии: сначала посчитайте, сколько виртуальных машин у вас реально критичны. Обычно из полусотни VM бизнес встанет без пяти-шести, а остальные переживут переезд спокойно. Планировать миграцию всего парка разом - верный способ не сделать её никогда. Начинать надо с некритичного, набирать опыт на нём и только потом трогать то, за что отвечаете головой. Сравнение платформ, между которыми обычно и выбирают, у нас разобрано отдельно - Proxmox против ESXi, Hyper-V и KVM.

Миграция: грабли, о которых не пишут в 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 внутри одного кластера - это позволяет обновлять инфраструктуру поэтапно. Что такое vCenter и зачем он в этой схеме, разбираем в отдельном материале - vCenter Server и его роль.

И ещё одна деталь: в 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 и vCenter. А если в планах не обновление, а перенос физических серверов в виртуальные, - есть разбор методов и инструментов P2V.

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

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

Для крупных enterprise-инсталляций с существующими инвестициями в vSphere-экосистему платформа по-прежнему мощнейшая: лимиты закрывают любые задачи, есть нативный Kubernetes, поддержка DPU, а в девятой ветке добавились Memory Tiering и заметно ускоренная работа с виртуальными GPU. Экосистема вокруг vSphere (vSAN, NSX, Aria) создаёт интеграционный эффект, который трудно воспроизвести на альтернативных платформах.

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

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

Короткие ответы на частые вопросы

Что такое VMware ESXi простыми словами?
Гипервизор первого типа: операционная система, которая ставится прямо на сервер, без промежуточной ОС, и позволяет запускать на нём десятки виртуальных машин. Управляется удалённо - через веб-интерфейс хоста или централизованно через vCenter.

Какая версия ESXi последняя?
На июль 2026 - девятая ветка: ESX 9.0 вышла в июне 2025, следом ESX 9.1. Обратите внимание на имя: с vSphere 9 продукт официально называется ESX, без «i».

Чем ESX 9 отличается от ESXi 8?
Ключевое практическое: Memory Tiering вышел в общую доступность (NVMe работает как дополнительный уровень оперативной памяти), режим FIPS включён по умолчанию, радикально ускорены операции с виртуальными GPU. Плюс vSphere 9 распространяется в составе VMware Cloud Foundation, а не отдельным продуктом.

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

Мой сервер 2016 года потянет ESXi 8?
Скорее всего нет. Восьмая версия требует Intel Skylake или AMD EPYC Naples и новее - Broadwell и Haswell инсталлятор не примет. Для девятой ветки список поддерживаемого железа ещё уже, и сверять надо конкретную модель по Broadcom Compatibility Guide.

Можно ли откатиться после обновления?
С 7.0 и новее на 6.x - нет: схема разделов загрузочного диска меняется, нужен полный восстановление из бэкапа. Между 8.x и 7.x откат возможен, если не трогали bootbank-разделы.

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