Чем заменить vSphere: Proxmox, oVirt и отечественные платформы в сравнении

MAATRIX

Если у вас в инфраструктуре ещё живёт VMware vSphere, к концу лета 2026 года вопрос «а что вместо него» перестал быть теоретическим почти для всех: у кого-то заканчивается лицензия и продление внезапно оказывается кратно дороже, у кого-то заказчик требует продукт из реестра отечественного ПО, а у кого-то просто не осталось официального канала для покупки новых лицензий в России. Разбираемся честно: чем реально отличаются Proxmox VE, oVirt и отечественные коммерческие платформы виртуализации, где у каждой грабли и кому какой вариант подходит.

Proxmox VE: путь наименьшего сопротивления

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

Кластер собирается буквально одной командой с узла, который уже состоит в кластере:

pvecm add 10.0.0.11

После этого узел появляется в общем веб-интерфейсе, кворум считается автоматически через corosync, а HA-группы настраиваются декларативно:

ha-manager add vm:101 --group prod-group --state started

Статус кластера и кворума — одной командой, без переключения между отдельными панелями:

pvecm status

Сильные стороны Proxmox VE для миграции с vSphere:

• Низкий порог входа. Администратор, знакомый с Linux и KVM, разберётся с интерфейсом за пару дней, а не за курс сертификации.
• Живая миграция и HA включены сразу, без отдельных лицензий на функции — то, за что в vSphere раньше платили отдельно.
• Огромное community: активные форумы, регулярные релизы, понятная документация — типичные проблемы уже кем-то разобраны.
• Встроенный бэкап (Proxmox Backup Server) с инкрементальными снапшотами и дедупликацией.
• Опциональная коммерческая поддержка по подписке — кластер работает и без неё.

Честные ограничения. Proxmox — не полный клон vCenter: экосистема сторонних интеграций (мониторинг, оркестрация, резервное копирование сторонних вендоров) заметно уже, чем у vSphere, хотя разрыв сокращается. DRS-аналога (автобалансировки нагрузки между узлами) в классическом смысле нет — балансировка чаще делается вручную или скриптами. И, что важно для формальных закупок, Proxmox VE как продукт европейского разработчика не входит в реестр отечественного ПО — там, где это требование обязательно, Proxmox сам по себе не закрывает формальный критерий, даже если технически полностью устраивает.

Если вы уже думаете о переходе на Proxmox с классического KVM без веб-обвязки или сравниваете его с более консервативным вариантом того же класса, у нас есть отдельные разборы — Proxmox против голого KVM и XCP-ng как альтернатива Proxmox — оба варианта решают ту же задачу немного разными средствами.

oVirt: ближе к привычному enterprise-подходу

oVirt — тоже открытая платформа на KVM, но архитектурно устроена иначе и целится именно в замену vCenter-подобной модели управления. Здесь есть отдельный компонент oVirt Engine — центральная точка управления кластером, дата-центрами, пулами хранения и политиками, концептуально ближе к vCenter Server, чем панель Proxmox. Engine можно развернуть как отдельную ВМ (self-hosted engine) внутри самого кластера, без выделенного физического сервера под неё.

Типичный сценарий развёртывания self-hosted engine:

hosted-engine --deploy

Мастер разворачивания интерактивно проведёт через настройку сети, хранилища для engine (NFS, iSCSI, Gluster) и параметры управляющей ВМ. После установки Engine доступен через веб-консоль, где заводятся дата-центры, кластеры, сети и хранилища — узнаваемая для администратора vSphere структура: Data Center → Cluster → Host, а не плоский список узлов, как в Proxmox.

Сильные стороны oVirt для команды с опытом vSphere:

• Понятийная модель ближе к привычной: иерархия дата-центров и кластеров, политики размещения ВМ — переучиваться приходится меньше, чем на плоской модели Proxmox.
• Более строгая enterprise-ориентация архитектуры: отдельный слой Engine, интеграция с Red Hat-экосистемой (oVirt исторически связан с проектом, из которого вырос RHV).
• Открытый код и отсутствие лицензионных отчислений, как и у Proxmox.

Честные ограничения. oVirt сложнее в первичном развёртывании: минимум для self-hosted engine — отдельное общее хранилище под ВМ Engine, и на практике комфортный кластер разворачивается от трёх физических узлов, а не от двух, как можно стартовать в Proxmox. Community заметно меньше — если у вас нестандартная проблема, готового ответа на форуме может не найтись, и придётся разбираться по логам самостоятельно. Темп релизов и активность апстрима в последние годы неровные — после того как Red Hat сосредоточился на коммерческом RHV/OpenShift Virtualization, часть импульса разработки сместилась туда, и это стоит учитывать на горизонт нескольких лет. Как и Proxmox, oVirt не входит в реестр отечественного ПО.

Отечественные платформы виртуализации: когда реестр — не опция, а требование

Отдельная категория вариантов — коммерческие платформы виртуализации российских разработчиков, включённые в реестр отечественного программного обеспечения. Здесь мы намеренно не называем конкретные продукты: рынок меняется, состав реестра пересматривается, а конкретные версии и возможности на момент вашего обращения могут отличаться от того, что можно достоверно написать в обзорной статье. Дальше — про категорию в целом, по тем же критериям, что и для Proxmox с oVirt.

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

• Формальный статус в реестре. Для госзаказчиков, объектов КИИ и части регулируемых отраслей наличие продукта в реестре — не пожелание, а условие допуска к закупке. Здесь отечественная платформа выигрывает по определению: ни Proxmox, ни oVirt этому критерию не соответствуют независимо от технических качеств.
• Русскоязычная коммерческая поддержка с SLA. В отличие от community-моделей Proxmox и oVirt, здесь обычно есть договор с юрлицом, гарантированное время реакции и эскалация — требование многих регламентов ИТ-поддержки и аудитов.
• Сертификация под требования регуляторов. Некоторые платформы проходят сертификацию ФСТЭК под определённые классы защищённости — обязательное условие для систем с определёнными категориями данных.

Честные ограничения, о которых стоит знать заранее. Зрелость и стабильность у отечественных платформ виртуализации в среднем ниже, чем у Proxmox (который развивается открыто и непрерывно уже больше пятнадцати лет) — это не значит, что продукт хуже технически, но означает меньше лет продакшен-эксплуатации у разных независимых пользователей и меньше публично задокументированных кейсов на нестандартные ситуации. Community здесь по определению не публичная, как форум Proxmox: обсуждения чаще идут внутри закрытых каналов поддержки вендора, поэтому самостоятельно нагуглить решение чужой проблемы получается реже. Кривая обучения для команды, привыкшей к vSphere или Proxmox, тоже не нулевая — интерфейс и терминология у разных отечественных платформ отличаются сильнее, чем можно ожидать, унифицированного стандарта нет. И коммерческая поддержка стоит денег: сравнивая совокупную стоимость владения с открытой платформой, закладывайте стоимость лицензий и подписки в расчёт, а не сравнивайте только capex на первую закупку.

Пять критериев, по которым реально стоит сравнивать

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

1. Зрелость и стабильность платформы. Сколько лет продукт в продакшене у разных независимых организаций, как часто выходят критичные патчи безопасности, насколько предсказуем апгрейд между мажорными версиями. Возраст и объём практики важнее списка функций в буклете.
2. Управление кластером и высокая доступность. Насколько просто и надёжно настраивается HA, живая миграция, автоматический рестарт ВМ при падении узла, работа с общим хранилищем. Важно не «есть ли фича», а сколько шагов нужно, чтобы включить её и потом эксплуатировать без сюрпризов.
3. Кривая обучения для команды с опытом vSphere. Насколько знакомая терминология, похожа ли модель управления (Data Center → Cluster → Host, роли, политики), сколько времени займёт довести администратора до самостоятельной работы.
4. Реестр отечественного ПО и формальные требования. Обязателен ли этот критерий для организации (госконтракт, КИИ, внутренняя политика закупок) или это просто «было бы неплохо». Если обязателен — он автоматически отсекает Proxmox и oVirt независимо от их технических достоинств.
5. Community против коммерческой поддержки. У кого будете спрашивать, когда что-то сломается в 2 часа ночи: у форума с миллионами прочтений похожих тем (Proxmox), у более узкого, но открытого сообщества (oVirt), или у линии поддержки по договору с гарантированным SLA (отечественная платформа). Вопрос не в том, что лучше в вакууме, а что соответствует уровню внутренней экспертизы команды и терпимости бизнеса к простою.

Сравнительная таблица и рекомендации по сценариям

Рекомендации по сценариям, без универсального «правильного» ответа:

• Небольшая команда, нет требования по реестру, нужен быстрый и надёжный результат. Proxmox VE — самый практичный выбор: быстро разворачивается, community закрывает большинство вопросов, HA и бэкап работают из коробки.
• Команда с enterprise-дисциплиной, привычная к иерархии vCenter, готова к более сложному первичному внедрению. oVirt даёт более знакомую модель управления, если время на изучение архитектуры Engine и self-hosted deployment заложено заранее.
• Требование реестра обязательно (госзаказчик, КИИ, внутренний комплаенс). Выбор фактически предопределён: нужна отечественная платформа из реестра, и обсуждать стоит не «нужна ли она», а какого вендора и с каким уровнем поддержки брать под бюджет и SLA.
• Гибридный контур: часть систем под формальными требованиями, часть — нет. Разумно держать отечественную платформу под регулируемым контуром, а остальную инфраструктуру (dev/test, внутренние сервисы) — на Proxmox или oVirt, не переплачивая за лицензии там, где требований нет.
• Нужна предсказуемость поведения при отказе узла. Прежде чем собирать кластер на любой платформе, стоит понимать, зачем в HA-кластере нужен третий узел и как он предотвращает split-brain — см. кворум в кластере: зачем третий узел и высокая доступность в Proxmox при падении узла.

Частые вопросы