Подробный обзор zVirt — российская виртуализация в пост-VMware эпоху

Привет!

В нашем блоге есть отдельные обзоры всех ключевых гипервизоров и платформ виртуализации на рынке: VMware ESXi и vSphere; Microsoft Hyper-V; KVM и платформа Proxmox VE; Xen и XenServer; а также отдельный материал по выбору гипервизора, где есть их сравнения между собой.

Но всё это западные решения, которые не всегда и не всем подходят в российских реалиях 2026 года (хоть часть из них и опенсорсная). Особенно после того, как Broadcom купила VMware и перелопатила модели лицензирования с ценами (теперь продукты VMware для крупного бизнеса), а законодательство обязывает некоторые организации использовать отечественное ПО. На этом фоне активно выходят альтернативы. Старые, новые, локальные, опенсорсные, гибридные. Среди них — zVirt.

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

Причина не так важна: если вы попали в эту статью, значит хотите изучить zVirt от Orion Soft — российскую платформу серверной виртуализации, построенную вокруг гипервизора KVM.

Так что давайте приступим к самому подробному обзору zVirt в Рунете :)

Что такое гипервизор и зачем нужна виртуализация

Перед стартом кратко пробегусь по базовой теории. 

Итак, гипервизор – это программное обеспечение, которое создаёт виртуальные машины (ВМ), управляет ими и изолирует их операционные системы от реального оборудования. Гипервизоры бывают двух типов (вообще трёх, но третий, гибридный тип, нас не интересует в рамках этой статьи):

• Тип 1 (bare-metal) — ставится напрямую на чистую машину без операционной системы (ОС) и даёт прямой доступ к процессору, памяти и устройствам — его считают самым эффективным и надёжным вариантом. Это что-то вроде базовой ОС.

• Тип 2 (hosted) — устанавливается поверх обычной ОС (например, VMware Workstation или VirtualBox), что проще, но даёт дополнительную нагрузку на систему из-за ещё одного слоя абстракции, второй тип менее производительный.

Зачем нужны гипервизоры и виртуализация? Они абстрагируют ресурсы процессора, памяти, сети и другие, позволяя запускать десятки и сотни виртуальных машин на одном сервере. Это сильно экономит ресурсы (сервер можно рациональнее загрузить работой) и электроэнергию при прочих равных без виртуализации: если ресурсы одной ВМ освободились, их можно направить другой ВМ, а инфраструктуре (как следствие) нужно меньше физических серверов и мощностей. С виртуализацией компании экономят на закупках оборудования, администрировании, стойках (занимаемом пространстве), охлаждении и электричестве. 

Виртуализация позволяет размещать несколько разных рабочих задач (серверных ролей) на одном хосте: почтовые, файловые, прокси-серверы, VPN-шлюзы, DHCP и DNS-серверы, веб-серверы, CRM и ERP-системы, серверы разработки и любые другие.

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

Базу кратко разобрали, теперь переходим к обзору zVirt.

Что такое zVirt: импортозамещение и простота миграции

zVirt от Orion Soft (Орион)— это российская корпоративная платформа виртуализации на основе oVirt (свободная, кроссплатформенная система управления виртуализацией с открытым исходным кодом) с администрированием через единый интерфейс (REST API или GUI).

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

У платформы есть полностью русскоязычный веб-интерфейс управления, через который системные администраторы видят состояние хостов и виртуалок, управляют хранилищами и сетями, создают кластеры, настраивают безопасность, сетевую виртуализацию, репликацию и DR (послеаварийное восстановление). Консоль собирает в одном месте все объекты виртуализации, что особенно удобно для администрирования больших инфраструктур.

Orion Soft позиционирует zVirt как решение уровня VMware vSphere (ушла из России) — по функциональности это покрытие почти всего необходимого для управления виртуализированной инфраструктурой: включая виртуализацию SDN-сетей с микросегментацией трафика (похоже на VMware SRM), чтобы повысить безопасность.

Для некоторых заказчиков очень важно, что zVirt находится в реестре отечественного ПО с 03.12.2018 (запись №4984). Да, платформу начали разрабатывать задолго до санкций 2022 года, поэтому она, пожалуй, одна из самых зрелых среди конкурентов для виртуализации в России.

По данным tadviser.ru

Продукт занимает более 40% доли рынка реестровой виртуализации (430+ российских компаний, 12,000+ серверов виртуализации). Даже после того, как oVirt остался без поддержки Red Hat в 2024 году, zVirt продолжил своё развитие, так что это полноценный самостоятельный и независимый форк.

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

Выше на схеме можете изучить архитектуру миграции ВМ VMware-zVirt — это специальный конвертер, через который реализована М2М-миграция ВМ из сред виртуализации, а также P2V-миграцию физических машин на zVirt (можно одновременно запускать несколько таких миграций, до 20 ВМ за раз).

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

Агент собирает конфигурацию системы и считывает данные напрямую из файловой системы — через VSS в Windows и драйвер уровня ФС в Linux, с временной заморозкой записи для сохранения целостности. После этого начинается поэтапная репликация данных по сети на целевую площадку. Такой механизм позволяет одинаково просто мигрировать с зарубежных и российских платформ, а также выполнять P2V-переезды.

Архитектура zVirt: что выбрать Hosted Engine или Standalone

Архитектура zVirt унаследована от oVirt: есть управляющий контроллер и группа KVM-хостов, на которых работают виртуальные машины. Среду виртуализации zVirt можно развернуть в архитектуре Hosted Engine или Standalone, вендор рекомендует Hosted Engine — более практичный и отказоустойчивый вариант.

Архитектура zVirt Hosted Engine

В архитектуре Hosted Engine все сервисы и базы данных Менеджера управления zVirt (ключевого компонента платформы, о котором я расскажу дальше) работают внутри специальной виртуальной машины — ВМ Hosted Engine. По своей роли она близка к vCenter в экосистеме VMware: это центральный узел управления, который координирует работу кластера. ВМ Hosted Engine запускается на хостах виртуализации с соответствующей ролью и при этом управляет этими же хостами, замыкая контур управления внутри самой платформы. Такие дела.

Главное достоинство Hosted Engine архитектуры — не нужен отдельный физический сервер под менеджер управления (тот самый Standalone). При этом Hosted Engine может работать в режиме высокой доступности (HA) и автоматически перезапускаться на другом хосте при сбое. 

Минимум для работы Hosted Engine:

• Собственно сам хост (или несколько для высокой доступности);

• Виртуальная машина с Менеджером управления на хосте(ах) c ролью HostedEngine;

• Хранилище (внешняя СХД или локальное хранилище для домена хранения), доступное всем узлам кластера.

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

Архитектура zVirt Standalone

В архитектуре Standalone менеджер управления zVirt разворачивается на отдельном сервере с установленной средой исполнения zVirt Node. Такой сервер полностью изолирован от виртуализируемых нагрузок и не зависит от состояния кластера виртуализации. Технически менеджер можно разместить и внутри виртуальной машины, но для продакшена лучше использовать физический сервер или KVM-виртуализацию.

Минимум для работы Standalone:

• Один Standalone-хост; 

• Один хост-гипервизор (но лучше два для высокой доступности);

• Хранилище (внешняя СХД или локальное хранилище для домена хранения), доступное всем узлам кластера;

Архитектура Standalone в целом подходит для любых рабочих нагрузок, но в целом это решение больше для разработки и тестовых сред, чем для прода. Этот вариант выбирают, когда нужен максимально простой и предсказуемый контур управления без дополнительных зависимостей.

Компоненты zVirt

А вот теперь переходим к компонентам — у zVirt есть несколько логических слоёв и сервисов для администрирования.

1. Менеджер управления

С технической точки зрения — это Java-приложение на базе Wildfly. А с точки зрения пользователя — веб-сервис, принимающий команды от администратора и планирующий действия: где разместить новую ВМ, как перераспределить ресурсы, какие политики безопасности применить. Менеджер управления хранит конфигурацию и следит за состоянием кластера, а также использует набор файлов конфигурации, баз данных и сервисов.

2. Хосты и среда исполнения zVirt Node

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

В основе zVirt лежит собственная среда исполнения виртуализации — zVirt Node (распространяется в виде ISO-файла из официального репозитория). Это минимальная ОС и рабочий слой, на котором запускаются виртуальные машины и их ресурсы: CPU, память, диски, сетевые интерфейсы. Эта среда общается с центральным менеджером управления и берёт на себя управление вычислительными ресурсами, сетями и хранилищами хоста, предоставляя их виртуальным машинам по командам центрального менеджера.

Для работы хоста zVirt Node использует набор компонентов, каждый из которых отвечает за свой уровень виртуализации и управления:

• Kernel-based Virtual Machine (KVM) — загружаемый модуль ядра Linux, который обеспечивает аппаратную виртуализацию с опорой на расширения Intel VT-x и AMD-V. Сам KVM работает в пространстве ядра, а гостевые системы запускаются как отдельные процессы QEMU в пользовательском пространстве. Через этот механизм физические ресурсы сервера — процессор, память и устройства ввода-вывода — становятся доступными виртуальным машинам.

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

• libvirt — универсальный слой управления виртуализацией. Libvirt отвечает за жизненный цикл виртуальных машин и связанных с ними виртуальных устройств. Когда управляющий компонент zVirt отправляет команды на запуск, остановку или перезагрузку ВМ, именно libvirt обеспечивает их корректное выполнение на соответствующих хостах.

• VDSM — служебный демон zVirt, который связывает всё воедино. VDSM выполняет операции над виртуальными машинами и хранилищами, координирует взаимодействие между узлами кластера и следит за состоянием ресурсов хоста — процессора, памяти, дисков и сети. Кроме того, он отвечает за диспетчеризацию задач при создании ВМ, сбор статистики и журналов. Экземпляр VDSM работает на каждом хосте и получает команды напрямую от менеджера управления zVirt.

Так под капотом у zVirt знакомая многим связка из KVM + QEMU + libvirt.

3. Хранилище в zVirt

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

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

Домен данных (Data Domain)

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

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

Проще говоря, если в инфраструктуре есть zVirt, то почти всё хранилище — это домены данных.

Домен ISO (устаревший)

Ранее домен ISO использовался для хранения установочных ISO-образов операционных систем, гостевых агентов и драйверов (в том числе для Windows). Такой подход разделял данные ВМ и установочные носители.

В актуальной архитектуре zVirt от этого отказались. Теперь ISO-файлы загружаются напрямую в домены данных, а отдельный ISO-домен больше не применяется. Домен хранения ISO официально не поддерживается.

Домен экспорта (устаревший)

Экспортный домен применялся как временное хранилище для переноса образов виртуальных машин между разными центрами данных или инсталляциями zVirt.

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

Ограничения устаревших доменов

И домены ISO, и домены экспорта работали исключительно с файловыми хранилищами:

• NFS

• POSIX-совместимые ФС

• GlusterFS

В современных инсталляциях zVirt от этих схем стараются уходить.

4. Хранилище данных (Data Warehouse, DWH) в zVirt

Менеджер управления zVirt включает встроенное Хранилище данных (Data Warehouse) — компонент, который собирает и аккумулирует статистику по всей виртуализированной среде.

DWH хранит данные мониторинга хостов, виртуальных машин, доменов хранения.

Из чего состоит DWH

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

• Служба ovirt-engine-dwhd — отвечает за репликацию данных из рабочей базы менеджера управления в базу истории.

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

5. Сети в zVirt

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

Логические сети

zVirt оперирует понятием логических сетей. Логическая сеть задаёт маршрут и назначение определённого типа трафика и позволяет изолировать потоки данных друг от друга или виртуализировать физическую топологию.

По умолчанию в системе создаётся логическая сеть ovirtmgmt. Она помечена как сеть управления и используется для обмена служебным трафиком между Менеджером управления и хостами.

Разделение сетевого трафика

Дополнительно администратор может определить отдельные логические сети для разных типов нагрузки:

• Сеть виртуальных машин — основной пользовательский трафик ВМ;

• Сеть хранения — трафик, связанный с доступом к хранилищам (NFS, iSCSI и т.д.);
  Сеть миграции — трафик Live Migration виртуальных машин;

• Сеть отображения — трафик удалённого доступа к ВМ (SPICE или VNC);

• Сеть Gluster — специализированный трафик распределённого хранилища Gluster.

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

Какой сервер выбрать для zVirt (требования к аппаратному обеспечению)

Так как архитектуры у zVirt две, то и требования можно поделить на Hosted Engine и Standalone. Данные взяты с Orion Soft Wiki, там же вы можете подробнее изучить нюансы, а для хоста zVirt я отдельно собрал информацию и систематизировал для вашего удобства.

Требования к хосту zVirt (кратко)

Требования к виртуальной машине HostedEngine zVirt 

Требования к хосту с ролью HostedEngine zVirt

Требования к Standalone-хосту zVirt

Ключевые возможности zVirt

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

• Централизованное управление — единая консоль позволяет управлять всеми объектами виртуальной среды: хостами, виртуальными машинами, сетями и хранилищами.

• Вычислительное ядро на KVM — zVirt строится на мощном гипервизоре KVM, с высокой производительностью и отличной совместимостью с Linux-гостевыми ОС.

• Развертывание и архитектуры — платформа поддерживает разные схемы развёртывания — от Standalone до Hosted Engine (рекомендуемая для управления кластером).

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

• Высокая отказоустойчивость и поддержка DR‑сценариев через механизмы кластеризации и HA — при сбое хоста виртуальные машины автоматически перезапускаются на других узлах и сохраняют доступность без участия администратора. 

• Работа с кластерами — zVirt поддерживает объединение хостов в кластеры для масштабирования рабочей нагрузки, отказоустойчивости и удобного управления.

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

• Мониторинг и визуализация — инструменты визуализации дают древовидные диаграммы для обзора инфраструктуры, позволяют отслеживать состояния объектов инфраструктуры и их взаимосвязи.

• Ролевая модель и контроль доступа — функции разграничения прав и роли позволяют гибко управлять доступом к возможностям платформы.

• Поддержка автоматизации — zVirt предоставляет встроенные механизмы автоматизации. А zVirt Ansible позволяет автоматически настраивать систему, управлять пользователями и виртуальными машинами после установки. Это проще, чем работать через REST API или SDK, и легко интегрируется с другими модулями Ansible.

Плюсы, минусы и конкурентные преимущества zVirt

Если компании нужна отечественная платформа виртуализации с сертификацией для задач импортозамещения, zVirt выглядит как взрослое и продуманное решение. По логике управления она ближе к VMware, поэтому администраторам с таким бэкграундом придётся немного перестроиться: другие термины, своя структура интерфейса, иные сценарии администрирования. Зато адаптация проходит достаточно быстро.

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

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

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

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

Он не универсален и не бесплатен, но в условиях 2026 года это часто и не нужно. Если задача — стабильная, управляемая и предсказуемая платформа под бизнес-нагрузки, zVirt отлично подходит под неё.

А серверное оборудование под zVirt, как обычно, помогут подобрать менеджеры Сервер Молл — ребята предложат решение под ваш бюджет и задачу, бесплатно проконсультируют и отправят КП за час.

Спасибо, что дочитали до конца. Если понравилась, то добавляйте блог Сервер Молл в закладки (Ctrl-D). Впереди ещё много интересных статей, в том числе про российские платформы виртуализации :)