Гипервизор — это программный слой, который создаёт виртуальные машины, изолирует их друг от друга и распределяет между ними физические ресурсы сервера: процессорные ядра, оперативную память, хранилище и сетевые интерфейсы. Благодаря ему один сервер может одновременно запускать несколько независимых операционных систем и приложений.
Гипервизор нужен, чтобы эффективнее использовать оборудование, быстрее разворачивать новые системы, разделять рабочие нагрузки и управлять ими независимо. Для одного сервера обычно достаточно 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 в узлах кластера;
-
наличие оборудования в каталоге совместимости выбранной платформы;
-
запас слотов, памяти, сетевых портов и накопителей для расширения.
Если строится кластер высокой доступности, расчёт «все серверы загружены почти полностью» не подходит. После отказа одного узла (или нескольких, если требования по доступности повышены) оставшиеся должны принять его ВМ без критической нехватки процессора, памяти и производительности хранилища.
Серверы для гипервизора
Краткий обзор популярных гипервизоров и сравнительный анализ
Сегодня нельзя корректно поставить в один ряд 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
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 и российские платформы. Добавлены матрица выбора, инфраструктурные сценарии и сравнение стоимости миграции, требований к оборудованию и компетенциям команды.

