Эксперты в подборе IT-оборудования
Вопрос «какой гипервизор выбрать» для многих команд стал не абстрактным - а вполне конкретным. И ответ начинается с понимания, как ESXi менялся от версии к версии.
Давайте разложим всё по полочкам: от первого ESX 1.0 до девятой ветки - что росло, что отпиливали и зачем. Спойлер: за 20 с лишним лет гипервизор прошёл путь от «запускает пару VM на одном сервере» до «оркестрирует тысячи контейнеров и работает на ARM». А заодно успел дважды сменить имя - и в 2025 году вернулся к исходному.
VMware ESXi прошёл путь длиной в два десятилетия. Первый ESX 1.0 появился в 2001 году - тогда это был просто bare-metal гипервизор с поддержкой гостевых Windows и Linux. Ни vMotion, ни кластеров, ни даже нормальной консоли управления. Просто виртуальные машины на голом железе. Зато сама идея - запустить несколько ОС на одном физическом сервере без промежуточной операционной системы - была революционной.
| Версия | Год выпуска | Конец поддержки | Ключевое событие |
|---|---|---|---|
| ESX 1.0 | 2001 | - | Первый bare-metal гипервизор VMware |
| ESX 3.0 | 2006 | - | Появление vMotion |
| ESX/ESXi 3.5 | 2007 | 2013 | Первая версия ESXi (параллельно с ESX) |
| ESX/ESXi 4.0 | 2009 | 2015 | vSphere Distributed Switch, vDS |
| ESXi 4.1 | 2010 | 2016 | Удаление Service Console |
| ESXi 5.0 | 2011 | 2018 | Полный переход на ESXi, VAAI |
| ESXi 5.5 | 2013 | 2020 | Network I/O Control v3 |
| ESXi 6.0 | 2015 | 2022 | Virtual Volumes (VVOLs) |
| ESXi 6.5 | 2016 | 2023 | HTML5-клиент, Encrypted vMotion |
| ESXi 6.7 | 2018 | 2023 | Полноценный HTML5-клиент вместо Flash |
| ESXi 7.0 | 2020 | окт. 2025 (General Support) | Kubernetes (Tanzu), поддержка ARM |
| ESXi 8.0 | 2022 | окт. 2027 (General Support) | vHardware 20, DPU, новая схема разделов |
| ESX 9.0 | июнь 2025 | сент. 2027 | Возврат имени ESX, Memory Tiering, FIPS по умолчанию |
| ESX 9.1 | 2026 | по циклу девятой ветки | Развитие линейки в составе VCF 9.1 |
Цикл поддержки здесь показателен: VMware даёт 5 лет General Support и ещё 2 года Technical Guidance (без патчей безопасности). ESXi 7.0 вышел из General Support в октябре 2025, а Technical Guidance закончится в октябре 2027. Для ESXi 8.0 - 2027 и 2029 соответственно.
Деталь, которая сбивает с толку при поиске документации. Начиная с vSphere 9 продукт официально называется VMware ESX - без буквы «i» на конце. Broadcom вернул историческое имя, которое использовалось до 2007 года.
На практике это значит вот что. Ищете вы «ESXi 9» - и получаете разнобой: половина источников пишет по-старому, половина по-новому, официальные релиз-ноты Broadcom озаглавлены «VMware ESX 9.0». Продукт при этом тот же самый: это прямое продолжение линейки ESXi 8.0, а не отдельная ветка. Просто имя вернули к исходному.
Ещё один сдвиг: vSphere 9 распространяется в составе VMware Cloud Foundation 9.0. Отдельным продуктом, который покупают и обновляют сам по себе, гипервизор быть перестал - он часть платформы.
До версии 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 - раньше это включалось отдельно.
Вот где VMware ESXi показывает рост наглядно. Цифры в таблице ниже - это рекомендованные максимумы, протестированные и поддерживаемые вендором.
| Параметр | ESXi 4.0 | ESXi 5.0 | ESXi 6.0 | ESXi 6.7 | ESXi 7.0 | ESXi 8.0 (U2+) |
|---|---|---|---|---|---|---|
| Логических CPU на хост | 64 | 160 | 480 | 768 | 768→896 (U2) | 960 |
| RAM на хост | 1 ТБ | 2 ТБ | 12 ТБ | 16 ТБ | 24 ТБ | 24 ТБ |
| VM на хост | 320 | 512 | 1024 | 1024 | 1024 | 1024 |
| vCPU на VM | 8 | 32 | 128 | 128 | 256→768 (U1) | 768 |
| RAM на VM | 256 ГБ | 1 ТБ | 4 ТБ | 6128 ГБ | 6128 ГБ | 6128 ГБ |
| Хостов в кластере | 32 | 32 | 64 | 64 | 64 | 64 |
| iSCSI paths | 128 | 128 | 128 | 128 | 128 | 2048 |
Девятой ветки в этой таблице намеренно нет, и вот почему. Broadcom перестал публиковать конфигурационные максимумы статичным списком - теперь это онлайн-инструмент Configuration Maximums, где значения фильтруются по версии и продукту и правятся между апдейтами. Замораживать их в статье бессмысленно: цифра, актуальная сегодня, разъедется с реальностью через полгода. Если планируете инфраструктуру под ESX 9, сверяйтесь с этим инструментом на дату проекта, а не с любой статьёй, включая эту.
Рост с 64 логических CPU на хост (ESXi 4.0) до 960 (ESXi 8.0 U2) - это не просто «стало больше». Это отражение того, как серверное железо ушло от двухсокетных систем с 4-ядерными процессорами к монстрам на 128-ядерных AMD EPYC. Гипервизор должен был научиться работать с этими масш