Выберите ваш город

Какой гипервизор выбрать

28.01.2025
25 мин на чтение
40686

Гипервизор — это программный слой, который создаёт виртуальные машины, изолирует их друг от друга и распределяет между ними физические ресурсы сервера: процессорные ядра, оперативную память, хранилище и сетевые интерфейсы. Благодаря ему один сервер может одновременно запускать несколько независимых операционных систем и приложений.

Гипервизор нужен, чтобы эффективнее использовать оборудование, быстрее разворачивать новые системы, разделять рабочие нагрузки и управлять ими независимо. Для одного сервера обычно достаточно Hyper-V, Proxmox VE или минимального стека KVM. Для кластера уже важны централизованное управление, высокая доступность, живая миграция, резервное копирование и поддержка оборудования. Поэтому на практике выбирают не только гипервизор, но и построенную вокруг него платформу.

Привет!

В нашем блоге уже выходила статья о том, как выбрать сервер для виртуализации. Там я подробно рассказывал про оборудование, но почти не углублялся в программную часть. Теперь пришло время обсудить тёмную виртуальную сторону вопроса :)

Сразу дам короткую рекомендацию. Для небольшой Linux-ориентированной инфраструктуры часто рассматривают Proxmox VE или чистый KVM, для среды Microsoft — Hyper-V в составе Windows Server 2025, для существующего корпоративного VMware-кластера — актуальные компоненты VMware в составе VVF или VCF. Xen обычно выбирают через готовую платформу XCP-ng, а при импортозамещении сравнивают российские платформы, их редакции, реестровые записи и подтверждённую совместимость с оборудованием.

Готовы вы или нет — мы начинаем.

Определение гипервизора и виртуализации

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

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

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

Гипервизор — это компонент, который непосредственно запускает виртуальные машины и управляет доступом к аппаратным ресурсам. Если предложить автомобильную аналогию, то гипервизор — двигатель. Без него машина далеко не уедет, но одного двигателя для удобной поездки тоже маловато.

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

Например:

  • KVM — гипервизорный механизм в ядре Linux;

  • Hyper-V — гипервизорная роль Windows Server;

  • VMware ESX/ESXi — гипервизор, а vSphere, VVF и VCF — более широкие коммерческие платформы и наборы компонентов;

  • Proxmox VE — готовая платформа на базе KVM и LXC;

  • Xen — гипервизор, а XCP-ng — готовая платформа на его основе.

Поэтому вопрос «какой гипервизор выбрать» на практике почти всегда означает: «какой стек виртуализации выбрать вместе с управлением, поддержкой, резервным копированием и планом миграции».

Типы гипервизоров

Гипервизоры делят на два основных типа.

Тип Как работает Типичные сценарии Примеры
Type 1, или bare-metal Гипервизор работает на уровне оборудования, не использует операционную систему общего назначения, и формирует привилегированный слой, управляющий гостевыми ВМ Серверная виртуализация, кластеры, ЦОД, частные облака VMware ESX/ESXi, Hyper-V, KVM, Xen
Type 2, или hosted Гипервизор запускается как приложение поверх обычной пользовательской ОС Рабочие станции, разработка, тестирование, обучение VMware Workstation и Fusion, Oracle VirtualBox, Parallels Desktop

Гипервизор 1-го типа.

Гипервизор 2-го типа.

В реальной архитектуре граница бывает сложнее, чем на учебной схеме. Например, KVM является частью ядра Linux, а Hyper-V использует специальный родительский раздел Windows для управления. Тем не менее по способу выполнения гостевых ВМ и доступу к оборудованию их относят к серверным гипервизорам Type 1.

При этом такие решения, как Proxmox VE классифицировать как Type 2 неправильно. Это не отдельный хостовый гипервизор, работающий поверх Debian как обычное приложение, а готовая серверная платформа. Для полноценных виртуальных машин она использует KVM, а для системных Linux-контейнеров — LXC.


Иногда можно встретить термин «гибридный гипервизор», потому что KVM, как и Hyper-V являются частями полноценных операционных систем общего назначения, но для выбора корпоративной платформы такое разделение скорее запутывает картину. VMware Fusion и Workstation, Parallels Desktop - остаются настольными решениями Type 2, даже если используют аппаратное ускорение процессора.

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

Преимущества гипервизора

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

Основные преимущества выглядят так:

  • Быстрое развёртывание. Виртуальную машину можно создать из шаблона значительно быстрее, чем подготовить отдельный физический сервер. Это особенно удобно для тестовых сред, временных проектов и динамических нагрузок.

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

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

  • Миграция. При наличии совместимых узлов, сети и хранилища работающую ВМ можно перенести между серверами с минимальным перерывом или вообще без заметного простоя ("живая миграция"). У VMware эта функция называется vMotion, у Hyper-V — Live Migration. Аналогичные механизмы есть в KVM, Proxmox VE и XCP-ng.

  • Высокая доступность. Если один узел кластера выходит из строя, платформа может автоматически перезапустить его ВМ на исправных узлах — при условии, что диски виртуальных машин доступны оставшимся узлам или заранее реплицированы. Это не то же самое, что живая миграция: при внезапном отказе исходный сервер уже не работает, поэтому ВМ обычно приходится запускать заново.

  • Упрощённое обслуживание. Перед ремонтом или обновлением узла виртуальные машины можно переместить на соседние серверы, выполнить работы и затем вернуть нагрузки обратно.

  • Резервное копирование и репликация. Многие платформы имеют встроенные средства копирования либо интегрируются со специализированными системами. Здесь важно не путать резервную копию со снимком: snapshot зависит от исходной инфраструктуры и не заменяет независимый бэкап.

  • Масштабирование и автоматизация. API, шаблоны и инструменты оркестрации позволяют стандартизировать развёртывание ВМ и управлять инфраструктурой как единым пулом ресурсов.

Серверы для гипервизора

При выборе железа необходимо отталкиваться не только от числа виртуальных машин.

Для рабочей виртуализации важны:

  • поддержка процессором аппаратной виртуализации и IOMMU;

  • достаточный объём памяти с учётом отказа одного узла;

  • производительность и задержки дисковой подсистемы;

  • резервирование сетевых подключений;

  • совместимость RAID-, HBA-, сетевых и GPU-адаптеров;

  • возможность установить одинаковые или совместимые CPU в узлах кластера;

  • наличие оборудования в каталоге совместимости выбранной платформы;

  • запас слотов, памяти, сетевых портов и накопителей для расширения.

Если строится кластер высокой доступности, расчёт «все серверы загружены почти полностью» не подходит. После отказа одного узла (или нескольких, если требования по доступности повышены) оставшиеся должны принять его ВМ без критической нехватки процессора, памяти и производительности хранилища.

Серверы для гипервизора

Новый
Dell PowerEdge R450 8SFF
CPU:
2x Intel Xeon Silver 4310 (12C 18M Cache 2.1 GHz)
RAM:
2x 16GB DDR4 RDIMM 3200MHz Dell
RAID:
RAID Dell H745 (4GB+BBU)
HDD:
noHDD (до 8 HDD 2.5'' SFF)

от 449 600

15 624 ₽/мес в лизинг

от 374 667

+ 74 933 НДС

Сконфигурировать
Refurbished
Dell PowerEdge R440 4LFF
CPU:
2x Intel Xeon Bronze 3204 (6C 8.25M Cache 1.90 GHz)
RAM:
2x 16GB DDR4 RDIMM 2666MHz (Поддержка до 512Гб максимально, 16 DIMM портов)
RAID:
RAID Dell H330 (ZM)
HDD:
noHDD (до 4 HDD 3.5'' LFF)

от 189 632

6 590 ₽/мес в лизинг

от 158 027

+ 31 605 НДС

Сконфигурировать

Краткий обзор популярных гипервизоров и сравнительный анализ

Сегодня нельзя корректно поставить в один ряд KVM, Proxmox VE, ESXi и VCF без пояснений. Один продукт является гипервизором, второй — готовой платформой, третий — ролью операционной системы, а четвёртый — комплексом для частного облака.

Базовая классификация выглядит так:

  • VMware ESX/ESXi + vSphere, VVF или VCF — гипервизор и коммерческая платформа для корпоративной инфраструктуры;

  • Hyper-V — роль Windows Server 2025 и гипервизорная технология Microsoft;

  • KVM — встроенный в Linux гипервизор, вокруг которого можно построить собственную платформу;

  • Proxmox VE — готовая открытая платформа на базе KVM и LXC;

  • Xen и XCP-ng — гипервизор и открытая платформа на его основе;

  • российские решения — преимущественно коммерческие платформы с централизованным управлением, поддержкой и собственными матрицами совместимости, как правило основанные на KVM (есть варианты и с Xen и совсем экзотичные с bhyve).

Гипервизор VMware ESXi

VMware ESX/ESXi остаётся основой большого количества корпоративных инфраструктур. В существующих средах версий 7 и 8 привычным остаётся название ESXi, а в актуальной линейке VMware Cloud Foundation 9.x Broadcom использует название VMware ESX. На август 2026 года актуальными выпусками являются VMware Cloud Foundation 9.1 и VMware vSphere Foundation 9.1.

Сам гипервизор предоставляет виртуальный вычислительный слой, но основные кластерные возможности раскрываются вместе с vCenter и соответствующей редакцией платформы. В зависимости от приобретённого пакета инфраструктура может включать vMotion, vSphere HA, DRS, vSAN, сетевую виртуализацию, централизованный мониторинг, автоматизацию и инструменты восстановления.

Поэтому сравнивать «бесплатный гипервизор ESXi» с Proxmox VE уже некорректно. Актуальная коммерческая модель строится вокруг подписок и возможностей VVF и VCF. Лицензирование рассчитывается по числу физических ядер на лицензируемых хостах, причём действует минимум 16 ядер на каждый физический процессор. Точные условия необходимо сверять по договору и актуальным правилам Broadcom.

Сильная сторона VMware — зрелая экосистема управления, мониторинга, резервного копирования и интеграций. Особенно заметно это в больших средах, где уже настроены vCenter, сети, хранилища, политики безопасности и автоматизация.

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

Подробности о компонентах и архитектуре есть в нашем обзоре VMware ESXi и vSphere.


Гипервизор Microsoft Hyper-V

Hyper-V — гипервизор Type 1, но сейчас в серверной инфраструктуре он поставляется не как отдельный Hyper-V Server, а как роль Windows Server. Бесплатная самостоятельная редакция Microsoft Hyper-V Server завершилась на версии 2019; для нового проекта следует рассматривать роль Hyper-V в Windows Server 2025 либо Azure Local для соответствующих гибридных сценариев.

Hyper-V особенно логичен там, где команда уже работает с Active Directory, PowerShell, Failover Clustering, Windows Admin Center, System Center и преимущественно Windows-нагрузками. При этом гостевые ВМ не ограничены Windows: поддерживаются и распространённые Linux и другие х86-дистрибутивы.

В кластерной конфигурации доступны Live Migration, Cluster Shared Volumes, автоматический перезапуск ВМ после отказа узла и Hyper-V Replica. Управлять отдельными хостами можно через Hyper-V Manager и PowerShell, а для централизованного управления используют Windows Admin Center или System Center Virtual Machine Manager.

У Hyper-V нет отдельной платы именно «за гипервизор»: технология включена в Windows Server. Но это не делает всю инфраструктуру бесплатной. Windows Server лицензируется по физическим ядрам, а права на запуск гостевых экземпляров зависят от редакции. После полного лицензирования физических ядер хоста редакция Standard обычно даёт право запускать два виртуальных экземпляра Windows Server. Для каждой следующей пары таких ВМ физические ядра хоста необходимо лицензировать заново. Datacenter после полного лицензирования хоста предоставляет право запускать неограниченное количество виртуальных экземпляров Windows Server. Конкретные условия зависят от канала поставки и лицензионного соглашения. Общие возможности Hyper-V в Windows Server 2025 описаны в документации Microsoft.

Для Windows-инфраструктуры Hyper-V может снизить количество отдельных компонентов и упростить работу команды. Для Linux-ориентированного частного облака или среды с большим количеством разнородных интеграций нужно отдельно сравнить экосистему управления и навыки администраторов.

Подробнее о функциях и лицензировании читайте в обзоре Microsoft Hyper-V.


Гипервизор KVM в составе платформы Proxmox VE

KVM, или Kernel-based Virtual Machine, является частью ядра Linux. В сочетании с QEMU он запускает полноценные виртуальные машины Windows, Linux и других гостевых ОС. Сам KVM распространяется как открытое ПО, но для рабочей инфраструктуры вокруг него нужны управление, сеть, хранилище, мониторинг, резервное копирование и механизмы высокой доступности.

Эти компоненты можно собрать самостоятельно с помощью libvirt, Cockpit, OpenStack, Ansible, Ceph и других инструментов. Такой подход даёт большую свободу, но требует сильной Linux-команды и ответственности за весь стек. Поэтому «KVM ничего не стоит» — только часть правды. Лицензия гипервизора не требует оплаты, однако сопровождение, интеграции и время инженеров входят в совокупную стоимость владения.

Готовой альтернативой самостоятельной сборке является несколько решений, в частности, одна из наиболее популярных - Proxmox VE. Это платформа, объединяющая KVM для виртуальных машин, LXC для Linux-контейнеров, веб-интерфейс, API, кластерное управление, HA, живую миграцию, программно-определяемые сети и поддержку разных вариантов хранения данных.

На август 2026 года актуальна Proxmox VE 9.2. Платформа распространяется как открытое ПО с полным набором функций. Коммерческая подписка приобретается для доступа к enterprise-репозиторию и технической поддержке и рассчитывается по занятым физическим процессорным сокетам. Условия и состав версии подтверждены в анонсе Proxmox VE 9.2.

Для резервного копирования можно использовать встроенные механизмы и/или отдельный Proxmox Backup Server. Но даже при наличии штатных средств копии нужно выносить за пределы исходного кластера и проверять восстановление.

Proxmox VE часто рассматривают для одного сервера, лаборатории и кластера малого или среднего бизнеса, но платформа подходит и для более крупных сред при правильной архитектуре. Основные ограничения обычно связаны не с числом ВМ, а с моделью поддержки, совместимостью конкретного оборудования, зрелостью процессов и опытом команды.

Отдельные подробности есть в обзорах KVM и Proxmox VE.


Гипервизор Xen и платформа XCP-ng

XenServer - Secure, Reliable, and High-Performance Virtualization Platform

Xen — гипервизор Type 1 с открытым исходным кодом. Он использует привилегированный управляющий домен Dom0 и гостевые домены DomU. Вокруг Xen существуют разные коммерческие и открытые продукты, поэтому сам гипервизор нельзя приравнивать к конкретной платформе или её модели лицензирования.

Один из актуальных вариантов — XCP-ng, открытая платформа на базе Xen и XAPI. Она предоставляет готовый установочный образ, управление пулами хостов, сетями и хранилищами, живую миграцию и интеграцию с Xen Orchestra. Через Xen Orchestra реализуются централизованное управление, резервное копирование, репликация и другие эксплуатационные функции.

На август 2026 года актуальным стабильным выпуском остаётся XCP-ng 8.3 LTS с заявленной поддержкой до 30 ноября 2028 года. Ветка 8.2 уже снята с поддержки, а предварительные версии будущих выпусков не следует устанавливать в рабочую среду. Статусы релизов опубликованы в официальной документации XCP-ng.

Саму платформу можно использовать без покупки лицензии, а коммерческая поддержка и готовая поддерживаемая поставка Xen Orchestra приобретаются отдельно. Поэтому стоимость зависит от числа хостов, выбранного уровня поддержки и того, будет ли команда самостоятельно обслуживать управляющий стек.

XCP-ng интересен хостинг-провайдерам, Linux-командам и организациям, которым нужна открытая альтернатива KVM с централизованным управлением. Перед выбором нужно проверить поддержку серверов, сетевых адаптеров, систем хранения, GPU и требуемых гостевых ОС. Вложенную виртуализацию в XCP-ng 8.3 следует считать экспериментальной возможностью для тестовых сред, а не гарантированной функцией для рабочих нагрузок. Проброс устройств и другие специфические функции тоже нужно заранее проверять на пилотном стенде.

Подробнее об архитектуре читайте в нашем обзоре Xen.


Российские платформы виртуализации

Российский рынок виртуализации живой и гибкий, на момент 2026 года в качестве актуальных примеров можно рассматривать zVirt, SpaceVM, VMmanager 6, Альт Виртуализация, ПК СВ «Брест» и vStack HCP. Это не один гипервизор в четырёх вариантах, а платформы с разной архитектурой, редакциями, вариантами хранения данных, средствами управления и условиями поддержки.

На текущий момент дистрибутивы имеют следующие записи в Едином реестре российского ПО:

  • zVirt — реестровая запись № 4984;

  • VMmanager 6 — № 9662;

  • гиперконвергентная инфраструктура vStack — № 11995;

  • ПК СВ «Брест» — №3742

  • Альт Виртуализация — №6487

  • облачная платформа SpaceVM — № 16085.

Наличие записи не означает, что любая редакция, дополнительный модуль или программно-аппаратный комплекс автоматически имеет тот же статус. Перед закупкой нужно сверить точное коммерческое наименование, правообладателя, номер записи, актуальность сведений и требуемые сертификаты. Реестр российского ПО и сертификат ФСТЭК — тоже не одно и то же.

При сравнении российских платформ особенно важны:

  • каталог совместимого серверного оборудования и СХД;

  • поддерживаемые гостевые ОС;

  • инструменты миграции из VMware, Hyper-V и KVM;

  • HA, живая миграция и работа без общего хранилища;

  • встроенное или внешнее резервное копирование;

  • доступность обновлений в закрытом контуре;

  • круглосуточная поддержка и сроки реакции;

  • интеграция с российскими ОС и средствами защиты;

  • возможность провести пилот на реальных нагрузках.

Название платформы в реестре — только отправная точка. Для рабочего проекта важнее подтверждённая совместимость всей связки: серверов, прошивок, адаптеров, СХД, гостевых ОС, резервного копирования и средств информационной безопасности.

Советы по выбору гипервизора

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

Матрица выбора по функциям, стоимости и сложности

Критерий VMware VVF/VCF Hyper-V KVM Proxmox VE Xen / XCP-ng Российские платформы
Стоимость лицензий Коммерческая подписка по физическим ядрам; минимум 16 ядер на каждый физический CPU Включён в Windows Server; стоимость определяется лицензиями хостов и гостевых Windows Server Сам гипервизор открыт; оплачиваются дистрибутив, поддержка и управляющий стек Открытая платформа; коммерческая подписка на поддержку и enterprise-репозиторий — по CPU-сокетам XCP-ng открыт; поддержка и готовая поставка Xen Orchestra оплачиваются отдельно Коммерческая модель зависит от продукта, редакции и числа хостов, сокетов или ядер
Поддержка Broadcom, партнёры и развитая экосистема Microsoft и партнёры Сообщество либо поставщик Linux-дистрибутива Сообщество, Proxmox и партнёры при наличии подписки Vates и партнёры либо сообщество Российский разработчик и партнёрская сеть
Высокая доступность vSphere HA и связанные компоненты Failover Clustering Зависит от выбранной платформы и оркестратора Встроенный HA-кластер Пулы XCP-ng и Xen Orchestra Зависит от платформы и редакции
Живая миграция vMotion Live Migration QEMU/KVM через libvirt или управляющую платформу Встроена Поддерживается XCP-ng Нужно проверять для конкретной редакции и типа хранилища
Резервное копирование Через компоненты платформы и развитую экосистему партнёров Базовые средства Windows и сторонние системы Зависит от собранного стека Встроенные задания и Proxmox Backup Server Xen Orchestra и сторонние системы Встроенные модули либо сертифицированные интеграции
Совместимость оборудования Строгий каталог совместимости Windows Server Catalog и требования производителя Широкая поддержка Linux, но официальная поддержка зависит от дистрибутива Широкая, однако производственную конфигурацию нужно тестировать Собственный список поддерживаемого оборудования Каталог совместимости каждого разработчика
Управление vCenter, VCF Operations и другие компоненты Hyper-V Manager, PowerShell, Windows Admin Center, SCVMM libvirt, Cockpit, OpenStack или собственный стек Единый веб-интерфейс, CLI и API Xen Orchestra и XAPI Единая консоль конкретной платформы
Требования к команде Знание VMware и состава VVF/VCF Сильные компетенции Windows Server и кластеризации Глубокое знание Linux, сетей, хранилищ и автоматизации Linux-компетенции среднего или высокого уровня Знание Xen, XAPI и Xen Orchestra Обучение у разработчика и знание выбранного продукта
Сложность миграции Низкая внутри VMware; высокая при переходе с другой архитектуры Ниже для Windows-нагрузок; средняя или высокая из других платформ Зависит от управляющего слоя; обычно средняя или высокая Есть инструменты импорта, но рабочая миграция требует пилота Средняя или высокая в зависимости от источника Зависит от конвертеров, совместимости и услуг разработчика

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

Выбор по сценарию инфраструктуры

Один физический сервер. Для нескольких ВМ без требований к HA обычно рассматривают Proxmox VE, Hyper-V или минимальный стек KVM. Если все приложения работают на Windows и лицензии Windows Server всё равно нужны, Hyper-V выглядит логично. Для смешанных Windows- и Linux-нагрузок удобен Proxmox VE. Но отказ одного хоста остановит все ВМ, поэтому независимые резервные копии обязательны.

Кластер малого или среднего бизнеса. Здесь нужно сравнивать не только гипервизор, но и кластерное управление, хранилище, HA и резервное копирование. Частыми кандидатами будут Proxmox VE, Hyper-V и XCP-ng. Выбор зависит от компетенций команды и уже используемых систем.

Windows-инфраструктура. Hyper-V хорошо вписывается в Active Directory, PowerShell, Failover Clustering и Windows Server. При большом числе Windows Server ВМ отдельно рассчитывают, не окажется ли Datacenter выгоднее многократного лицензирования Standard. Интересным моментом выглядит и то, что при лицензировании Windows-инфраструктуры и использовании другого гипервизора - стоимость лицензий чисто на Windows сохраняется неизменной, поэтому Hyper-V часто выглядит более экономичным, чем другие платные гипервизоры.

Linux-инфраструктура. Для команды с сильными Linux-компетенциями подойдут KVM и платформы на его основе. Proxmox VE сокращает объём самостоятельной сборки, а KVM с OpenStack даёт больше свободы для частного облака, но заметно повышает требования к эксплуатации.

Существующий VMware-кластер. Сначала нужно рассчитать стоимость продолжения эксплуатации на VVF или VCF и сравнить её со стоимостью перехода. Если инфраструктура стабильна, глубоко интегрирована и стоимость простоя высока, сохранение VMware может оказаться экономичнее быстрой миграции. Если подписка, оборудование или доступность поддержки стали проблемой, стоит пилотировать Proxmox VE, Hyper-V, XCP-ng или российскую платформу.

Частное облако. Для развитого частного облака сравнивают VCF, KVM/OpenStack и комплексные российские или гиперконвергентные платформы. Здесь особенно важны API, управление арендаторами, программно-определяемые сети, квоты, автоматизация и интеграция с Kubernetes.

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

Миграция, совместимость и требования к команде

Стоимость перехода на новый гипервизор не равна стоимости его лицензии. Более честная формула выглядит так:

Стоимость миграции = обследование и пилот + конвертация ВМ + допустимый простой + обучение команды + перенос сетей и хранилищ + замена интеграций + период двойного лицензирования + несовместимое оборудование.


Условно переход с VMware на открытую платформу может снизить текущие и будущие лицензионные расходы, но потребовать больше человеко-часов на миграцию и дальнейшее сопровождение. Переход на Hyper-V упрощается для Windows-нагрузок, но не отменяет пересчёт лицензий Windows Server. Российская платформа может решить задачу импортозамещения, однако стоимость проекта будет зависеть от услуг миграции, требуемой редакции и замены несовместимых компонентов.

До выбора целевой платформы нужно собрать данные о текущих ВМ, форматах дисков, режиме загрузки BIOS или UEFI, Secure Boot, виртуальных TPM, сетях, VLAN, проброшенных устройствах и зависимостях приложений. Отдельно проверяются гостевые драйверы, агенты резервного копирования и лицензии программ, привязанные к процессорам, MAC-адресам или аппаратным идентификаторам.

Для живой миграции узлы должны иметь совместимые процессорные функции. Даже процессоры одного производителя, но разных поколений могут потребовать маскирования CPU-флагов или ограничения набора инструкций. А миграция между Intel и AMD обычно означает остановку ВМ.

Также нужно заранее определить:

  • какие ВМ допускают остановку и на какое время;

  • какие приложения требуют отдельной кластеризации внутри гостевой ОС;

  • где будут находиться резервные копии;

  • как выполняется откат на исходную платформу;

  • кто будет поддерживать новый стек после завершения проекта;

  • можно ли получать обновления и поддержку в используемом сетевом контуре.

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

Вместо выводов

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

Если свести выбор к короткой логике:

  • для одного сервера и небольшого смешанного окружения часто подходит Proxmox VE;

  • для Windows-инфраструктуры стоит начать сравнение с Hyper-V в Windows Server 2025;

  • для Linux-среды и собственной платформы — с KVM;

  • для действующего зрелого VMware-кластера — с расчёта VVF или VCF 9.1 и реальной стоимости миграции;

  • для открытой платформы на Xen — с XCP-ng 8.3 LTS;

  • для импортозамещения — с пилота проверенных российских платформ и сверки конкретных редакций с реестром.

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

Если потребуется помощь, специалисты СЕРВЕР МОЛЛ подскажут, какое оборудование подойдёт для выбранного гипервизора, проверят возможности расширения и помогут сопоставить конфигурацию с требованиями проекта.

Спасибо, что дочитали статью. В нашем блоге есть отдельные подробные обзоры VMware, Hyper-V, KVM, Proxmox VE и Xen. Здесь мы оставили центральное сравнение, а за архитектурными подробностями и инструкциями можно переходить в соответствующий материал.

Обновление 04.08.2026. В статье добавлено прямое определение гипервизора, исправлена классификация Type 1 и Type 2 и отдельно объяснена разница между гипервизором, ролью ОС и платформой управления. Актуализированы VMware ESX/ESXi и VVF/VCF 9.1, Hyper-V в Windows Server 2025, KVM, Proxmox VE 9.2, Xen/XCP-ng и российские платформы. Добавлены матрица выбора, инфраструктурные сценарии и сравнение стоимости миграции, требований к оборудованию и компетенциям команды.


Автор

СЕРВЕР МОЛЛ

Поделиться
Комментарии
(4)
Михаил
02.06.2025
Абсолютно пропущены вопросы определения достаточности ресурсов. Если приложение работает медленно, первый вопрос - а достаточно ли ресурсов у хоста, а если недостаточно, то в чем недостаток. В процессоре собака зарыта. У VmWare есть стандартные средства определения перегрузки хоста по процессору, а у Hyper-V и КVM их нет. Про Xen не скажу, не пробовал его. Насколько я знаю, у Hyper-V дело полный швах, ничего, кроме загрузки процессора посмотреть нельзя, а уровень использования ресурса в принципе не может говорить о его достаточности. KVM имеет статистику, по которой можно определить недостаточность процессорных ресурсов, но я не видел ни одной реализации, где средства определения достаточности ресурсов встроены - производители одной из реализаций мне прямо сказали, что администратор должен изучить libvirt для того, чтобы понять статистику по процессору, которая показывается. Из ответа я делаю вывод, что вендор этого не знает. А это очень плохой знак - вендор не разбирается в том, что сделал, его дело - бантики для libvirt. Мой вывод такой - если готов иметь экспертизу выше, чем вендор, можно брать KVM. Не готов - только VmWare
СЕРВЕР МОЛЛ :
Михаил, спасибо за развёрнутый комментарий! Вопрос достаточности ресурсов не затронут сознательно — мы не полезли в дебри мониторинга, чтобы не перегрузить вводную общую статью по гипервизорам (хотя автор упомянул, что запас в 20-30% должен быть всегда). Что касается диагностики: по поводу VMware — да, там хорошие встроенные метрики, тот же vCenter с алёртами по CPU Ready и прочими вещами облегчает жизнь. Тут спору нет. А вот с Hyper-V я бы не был так категоричен. У него есть Performance Monitor (мониторинг производительности в реальном времени) и набор счётчиков, которые позволяют хотя бы примерно понять, в чём дело — тот же «Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time» и другие. Да, не так удобно, как с VMware, и многое приходится делать руками, но определить и устранить узкие места в системе можно. Про KVM — статистику можно получить через libvirt API, но для её сбора и продвинутого мониторинга нужны решения, вроде libvirt и/или Prometheus с экспортером, так как стандартные утилиты (virsh, virt-top или virt-manager) показывают лишь базовые метрики. Да, то что в libvirt много чего можно, но мало что из этого автоматизировано и визуализировано — это минус. Всё же libvirt — это не продукт с коробочной экспертизой, а скорее отвёртка: дали, а дальше крути сам. Решения от вендоров (например, Proxmox VE) — это действительно обёртка с удобным веб-интерфейсом и API для мониторинга, но для глубокого анализа нужно работать руками с CLI или интегрироваться с Zabbix/Grafana. А по вашему выводу — согласен: если админ готов копать глубоко — KVM отличный гибкий выбор. Не готов — VMware сильно упростит работу, но и стоит он прилично. Тут каждому своё. Но и Hyper-V не списывайте — он где-то посередине :) Спасибо ещё раз за комментарий!
ХМ
04.04.2025
Ключевой момент: XCP-ng не поддерживает вложенную виртуализацию.
СЕРВЕР МОЛЛ :
Добрый день! Да, вы правы — XCP-ng действительно не поддерживает вложенную виртуализацию нативно, это ограничение платформы Xen. Технически, можно попробовать включить её вручную через правку параметров Xen, но это неофициальный метод без гарантий стабильности. Если вам важна эта функция, лучше выбрать альтернативы, вроде Proxmox VE или VMware ESXi — они из коробки поддерживают nested virtualization.
Вадим
26.04.2024
Есть ли менее дорогие серверы для виртуализации до 150к? В статье представлены не самые дешевые варианты, даже одни из самых дорогих я бы сказал)
СЕРВЕР МОЛЛ :
Здравствуйте! Попробуйте конфигуратор Dell R440 (https://servermall.ru/config/dell-r440-4x3-5-ref) — это бюджетный восстановленный сервер с полноценной гарантией 5 лет и другими фичами :) Если из недорого выбираете, то смотрите на Ref-оборудование предыдущих поколений, там всегда можно подобрать что-то для нетребовательных задач. И не стесняйтесь писать нам в чат или звонить — мы бесплатно подбираем клиентам оборудование под их бюджет и задачу.
Дмитрий
26.03.2024
А что по импортозамещению?
СЕРВЕР МОЛЛ :
Добрый день! Планируем чуть позже сделать обзоры отечественных гипервизоров, можете подписаться на рассылку или заглядывайте в блог, чтобы не пропустить :)
Написать комментарий
Поля, отмеченные *, обязательны для заполнения

Больше статей

client consultations icon-delivery discount icon-facebook franchise icon-google_plus it-solutions icon-jivosite icon-menu icon-up icon-message payment icon-recall shops-local shops-network icon-solutions icon-support tasks icon-twitter Group 8 icon-user icon-viber icon-vk icon-watsup icon-watsup-2
Мы используем файлы 'cookie', чтобы обеспечить максимальное удобство пользователям.