oVirt: корпоративная виртуализация без VMware — рабочий опыт внедрения

Семёнов Евгений Сергеевич, директор АйТи Фреш. 15+ лет я строю корпоративные инфраструктуры, и последние два года основная часть проектов — это миграция с VMware vSphere на отечественные и open-source платформы. oVirt — один из самых зрелых вариантов: архитектура копирует vSphere, под капотом KVM+libvirt, нет подписок и лицензионных платежей. Расскажу, как мы в АйТи Фреш разворачиваем oVirt для среднего офиса — с реальными граблями и цифрами производительности.

Почему именно oVirt

После ухода VMware с российского рынка у бизнеса осталось три пути: Proxmox, zVirt (российская сборка oVirt), Hyper-V или просто upstream oVirt. У каждого свои плюсы, но oVirt выигрывает когда нужна корпоративная функциональность: сложная ролевая модель, интеграция с AD, SPM (Storage Pool Manager), продвинутые сетевые профили, гиперконвергенция с GlusterFS.

Основные возможности oVirt в 2025 году:

• Централизованный менеджер (engine) с web-UI и REST API.
• Живая миграция VM без прерывания работы, в том числе с живой миграцией хранилища.
• High Availability — автоматический перезапуск VM при падении хоста.
• Снэпшоты, клоны, шаблоны с cloud-init для быстрого развёртывания.
• Поддержка NFS, iSCSI, Fibre Channel, GlusterFS для хранилищ.
• Интеграция с Ansible, Terraform, OpenStack Keystone для ролевой модели.

Архитектура кластера

Минимальная production-инсталляция:

• oVirt Engine — управляющий сервер. Ставится либо на отдельную виртуалку вне кластера, либо как self-hosted engine (SHE) на самом кластере.
• Hypervisor Hosts — минимум 2 хоста на oVirt Node (минималистичный CentOS Stream) или RHEL 9.x с пакетами oVirt.
• Storage — NFS, iSCSI, Fibre Channel или GlusterFS. Минимум один домен Data, один ISO, один Export.
• Сеть — минимум два физических интерфейса: management+VM traffic и storage. В идеале — четыре с выделенными под migration и backup.

Для офиса до 50 РМ рекомендую: 2 хоста × (2 × Xeon Silver/Gold, 128 ГБ RAM, 2×480 GB SSD RAID1 для ОС, 4×4 TB NL-SAS RAID10 для VM) + сетевое хранилище Synology/QNAP по NFS либо гиперконвергентный Gluster на тех же хостах. У нас на стенде — Dell Xeon Platinum 8280 с 256 ГБ RAM, 40G Mellanox для storage-сети.

Установка Self-Hosted Engine

Самый популярный сценарий — self-hosted engine: сам управляющий сервер работает как VM на кластере, который он же контролирует. Это экономит железо и повышает отказоустойчивость.

# На первом хосте — CentOS Stream 9 + oVirt repo
dnf install -y centos-release-ovirt45
dnf install -y ovirt-hosted-engine-setup

# Запуск ассистента
hosted-engine --deploy

Ассистент задаёт десятки вопросов: имя кластера, сеть, storage для engine-VM (NFS/iSCSI/Gluster), пароль root для engine, DNS-имя engine. Процесс занимает 30–50 минут и в финале у вас есть working engine на отдельной VM.

После завершения — открываем https://engine.corp.example.ru/ovirt-engine и логинимся под admin@internal.

Подключение хранилища

Storage Domain — это место, где лежат диски VM. В oVirt есть несколько типов:

Для офиса до 50 РМ я обычно рекомендую NFS на отдельном NAS или гиперконвергентный Gluster на трёх хостах — он даёт отказоустойчивость без дополнительного железа.

Настройка сети

По умолчанию engine создаёт сеть ovirtmgmt, которая совмещает management и VM traffic. Для production это плохо. Разделяйте:

• ovirtmgmt — трафик engine-host (минимум 1 Гбит/с).
• VM-Network — пользовательский трафик VM, можно с VLAN.
• Storage-Network — трафик к NFS/iSCSI (10 Гбит/с+).
• Migration-Network — отдельный интерфейс для live migration (10 Гбит/с+).

В engine → Compute → Hosts → Network Interfaces можно назначить логические сети на физические интерфейсы, настроить bonding (802.3ad LACP предпочтительно) и тэггинг VLAN.

Создание VM

Через web-UI — Compute → Virtual Machines → New. Основные параметры:

• Cluster — целевой кластер (у нас обычно один).
• Template — базовый шаблон (Blank для первой VM, потом создаём свои).
• Operating System — для Windows выбираем Windows Server 2022/2025, для Linux — конкретный дистр.
• Memory, CPU — обязательно ставим гостевые дополнения через VirtIO.
• Disks — тип qcow2 с thin provisioning, либо preallocated для БД.
• Network — подключаем к VM-Network VLAN.

# Загрузка ISO с драйверами VirtIO
wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso

# Для загрузки ISO в oVirt storage
ovirt-imageio-client upload virtio-win.iso \
  --engine-url https://engine.corp.example.ru \
  --username admin@internal \
  --password-file /root/.ovirt-pass \
  --cafile /etc/pki/ovirt-engine/ca.pem \
  --disk-sparse \
  --storage-domain ISO-Domain

Для Windows Server 2022 требуются VirtIO-драйверы NetKVM, vioscsi, balloon, viostor, qemufwcfg — все есть в virtio-win ISO.

Мини-кейс: миграция с VMware на oVirt

В сентябре 2025 года к нам пришёл клиент — оптовая фармацевтическая компания, 130 сотрудников, 2 ESXi-хоста с 36 виртуалками. После отзыва лицензий VMware было принято решение мигрировать на oVirt. Дедлайн — 2 месяца до окончания коммерческой лицензии.

Процесс:

• Неделя 1: закупили два новых сервера Dell R750 + NAS Synology SA3410 с 48 ТБ NL-SAS и 4×800 ГБ NVMe SSD под кэш. Поставили CentOS Stream 9 + oVirt Node.
• Неделя 2: развернули self-hosted engine, подключили NFS-домен на Synology, настроили сети и live migration через 10G интерфейсы.
• Неделя 3-4: подготовили шаблоны Windows 2019/2022, написали Ansible-роли автоматизации деплоя, перенесли виртуалки через virt-v2v.
• Неделя 5-6: тестирование, миграция прод-VM в окнах обслуживания, параллельно VMware и oVirt работали 2 недели для отката.
• Неделя 7: отключение VMware, снятие лицензий, передача VMware-железа под тестовый контур.

Итог: 36 VM успешно переехали, средний простой на VM — 12 минут. Пиковая производительность оставалась на уровне VMware. Экономия на лицензиях — около 1,2 млн руб./год. Стоимость проекта — 380 000 руб. + стоимость нового железа, окупаемость 4 месяца.

High Availability и миграция

oVirt поддерживает HA из коробки. Для каждой VM в настройках есть checkbox «Highly Available» — при падении хоста VM автоматически запустится на другом. Условия:

• Диски VM должны лежать на shared storage (NFS/iSCSI/Gluster).
• Минимум два хоста в кластере со свободными ресурсами.
• Включен fencing (power management) для корректного изолирования упавшего хоста.

Fencing — это критичная фича. При пропаже хоста engine пытается через iDRAC/iLO/IPMI принудительно его выключить, чтобы избежать split-brain. Настраивается в свойствах хоста → Power Management.

Бэкапы

Встроенных бэкапов в oVirt нет — это отдельный продукт. Я использую три сценария:

• Снэпшоты + экспорт в Export Domain — старый способ, работает, но долго.
• Bareos/Bacula с oVirt-плагином — для инсталляций, где уже используется Bareos.
• RuBackup или Veeam для KVM — коммерческие решения с хорошей поддержкой oVirt API.

# Снэпшот через API
curl -X POST \
  -H "Accept: application/xml" \
  -H "Content-Type: application/xml" \
  -u "admin@internal:password" \
  https://engine.corp.example.ru/ovirt-engine/api/vms/$VM_ID/snapshots \
  -d '<snapshot><description>Backup 2025-12-03</description></snapshot>'

Типичные ошибки при внедрении oVirt

• Один хост в кластере. oVirt заточен на отказоустойчивость, минимум — два хоста. Иначе смысл теряется.
• Совмещение management и VM-трафика. При нагрузке management отваливается, engine теряет хосты, VM уходят в HA-перезапуск.
• Gluster на 1 Гбит/с. Для гиперконвергенции нужно минимум 10G, лучше 25G/40G.
• Отсутствие fencing. При падении хоста без fencing его VM останутся «повисшими», HA не сработает корректно.
• Снэпшоты в продакшене «на всякий случай». Длинная цепочка снэпшотов убивает производительность дисков. Снэпшоты — только для коротких окон.

Что использовать в 2025: oVirt или zVirt

zVirt — это российская сборка oVirt от Orion Soft, сертифицированная ФСТЭК. Если требуется соответствие 152-ФЗ и наличие технической поддержки с SLA на русском — zVirt. Если бюджет ограничен и есть внутренняя экспертиза — upstream oVirt. Архитектурно они одинаковые, разница в поддержке, локализации и сертификации.

FAQ — частые вопросы про oVirt

Что такое oVirt?

oVirt — open-source платформа виртуализации на базе KVM и libvirt, функционально близкая к VMware vSphere. Включает централизованный менеджер (engine), хосты виртуализации, живую миграцию, High Availability, интеграцию с внешним хранилищем или гиперконвергентным GlusterFS.

Подходит ли oVirt для офиса на 50 рабочих мест?

Да, базовая инсталляция из двух хостов и self-hosted engine полностью закрывает потребности среднего офиса. Для офиса на 50 РМ обычно достаточно 2 серверов по 128 ГБ RAM и 16 ядрам, которые держат 30–50 виртуальных машин с запасом.

Чем oVirt отличается от Proxmox?

Proxmox проще в старте и не требует отдельного менеджера. oVirt сложнее, но функциональнее — корпоративные фичи ближе к VMware: сложные сети, SPM, live migration с live storage, интеграция с AD для ролевой модели, гиперконвергентный Gluster из коробки.

Можно ли мигрировать с VMware на oVirt?

Да, есть утилита virt-v2v, которая конвертирует VMDK в qcow2 и переносит виртуалки на хосты oVirt. Для чистой миграции лучше погасить VM, сконвертировать, запустить на новом кластере. Живая миграция между платформами невозможна.

Поддерживает ли oVirt Windows VM?

Да, через VirtIO-драйверы. После первой установки Windows на виртуальную машину нужно поставить virtio-win ISO с драйверами сети, хранилища и balloon-памяти. На 2022/2025 Server всё работает стабильно.