Эксперты в подборе IT-оборудования
Установка zVirt идёт в три слоя. Сначала на каждый сервер ставится гипервизор zVirt Node. Потом разворачивается менеджер управления zVirt Engine: виртуальной машиной внутри кластера (Hosted Engine) или на отдельном сервере (Standalone). В конце в веб-портале создаются дата-центр, кластер и хранилища. Пошаговые экраны Orion soft подробно описала в своей инструкции, пересказывать их нет смысла.
Эта статья про то, что вики раскладывает по десятку страниц: какую схему выбрать под ваше число серверов, какое железо и сеть подготовить, где будет жить менеджер и что делать, если после перезагрузки портал пишет «backend недоступна». Большая часть проблем с zVirt появляется до того, как вставлен установочный образ.
Если торопитесь
Три сервера и общая СХД (iSCSI, FC или NFS) → Hosted Engine, вендор рекомендует именно его.
Есть отдельный сервер под управление и хочется, чтобы менеджер не зависел от общего хранилища → Standalone.
Два сервера → Hosted Engine на обоих, но без запаса: подробности в разделе про выбор схемы.
zVirt Engine - это менеджер управления: через него администрируют хосты, виртуальные машины, сети и хранилища всей среды. Если вы переезжаете с VMware, это аналог vCenter. Без Engine виртуальные машины продолжают работать на хостах, но создавать, мигрировать и настраивать их становится нечем.
| Компонент | Что делает | Где живёт |
|---|---|---|
| zVirt Node | гипервизор на базе KVM, запускает виртуальные машины | ставится на каждый физический сервер |
| zVirt Engine | портал администрирования, API, планировщик, служба backend | ВМ HostedEngine внутри кластера или отдельный сервер Standalone |
| DWH | хранилище истории и статистики для отчётов | рядом с Engine, от 1 до 100 ГБ в зависимости от размера среды |
| Домены хранения | хранилища для дисков ВМ, образов и самого Engine | СХД по iSCSI, FC, NFS или локальные диски |
| Логические сети | управление, миграция, хранилище, сети ВМ | порты и VLAN хостов |
С версии 5.0, вышедшей в конце апреля 2026 года, хосты работают на собственной гипервизорной ОС zVirt Node 2.0. Штатного программно-определяемого хранилища в платформе пока нет, Orion soft обещает его и встроенный бэкап в течение 2026 года. Если вы ещё выбираете между российскими платформами, сначала посмотрите сравнение zVirt, ROSA и «Альт Виртуализации»: там разобраны сертификаты и лицензии.
Вендор рекомендует Hosted Engine. Менеджер работает виртуальной машиной на хостах кластера, и отдельный сервер под него не нужен. При отказе хоста ВМ HostedEngine перезапускается на соседнем. Standalone проще устроен: менеджер стоит на своём физическом сервере и не зависит от того, что происходит с кластером.
| Hosted Engine | Standalone | |
|---|---|---|
| Где работает Engine | ВМ на хостах с ролью HostedEngine | отдельный физический сервер |
| Отказоустойчивость менеджера | есть, нужно минимум 2 хоста с ролью HostedEngine | нет, только внешними средствами (резервная копия, второй сервер) |
| Лимит | до 7 хостов с ролью HostedEngine в одной установке | - |
| Способ развёртывания | веб-консоль Cockpit или командная строка | только командная строка |
| Базы Engine и DWH | при установке только локально, перенос после | можно сразу вынести на отдельный сервер |
| Хранилище под менеджер | отдельный домен хранения, готовый до развёртывания | локальный диск сервера управления |
| Сколько серверов нужно | от 2, комфортно от 3 | от 1 под Engine + хосты |
Под реальность малого и среднего бизнеса это превращается в четыре типовые ситуации.
Три сервера и общая СХД. Классический случай для Hosted Engine: роль HostedEngine на всех трёх, при отказе одного хоста менеджер переезжает, а ВМ с включённой высокой доступностью перезапускаются на оставшихся двух. Именно такую схему вендор разбирает в пошаговой инструкции.
Два сервера и СХД. Hosted Engine формально работает: два хоста с ролью HostedEngine - это минимум для отказоустойчивости менеджера. Запаса в такой схеме нет. Когда один хост на обслуживании, второй держит и Engine, и все ВМ, а любой сбой в этот момент оставляет среду без управления. Считать ресурсы в такой схеме нужно так, чтобы один сервер вытягивал всю нагрузку.
Есть свободный сервер под управление. Старая, но исправная машина закрывает Standalone. Менеджер не делит ресурсы с рабочими ВМ и не зависит от домена хранения под Engine. Цена - нет автоматического переезда: если сервер управления умер, ВМ продолжат работать, но управлять ими будет нечем, пока менеджер не восстановят из резервной копии.
Нет общей СХД. Hosted Engine требует общего хранилища под ВМ менеджера, так что без СХД или NFS-сервера остаётся Standalone с локальными доменами хранения. Локальный домен привязан к одному хосту, поэтому живая миграция ВМ и автоматический перезапуск на другом хосте в такой схеме не работают.
У Hosted Engine есть и честный минус. После аварии питания, когда разом выключились хосты и СХД, менеджер поднимется только после того, как станет доступен его домен хранения. Порядок включения оборудования в такой схеме нужно знать заранее и держать в регламенте.
Минимальные требования zVirt 5.0 по документации Orion soft:
| Ресурс | Хост zVirt Node | ВМ HostedEngine | Сервер Standalone |
|---|---|---|---|
| Процессор | Intel 64 или AMD64 с аппаратной виртуализацией (Intel VT / AMD-V) и флагом NX; хосту с ролью HostedEngine - от 4 ядер | 4 vCPU | 4 ядра |
| Память | от 8 ГБ, до 12 ТБ на хост | 4 ГБ, до 50 хостов и 200 ВМ вендор советует 16 ГБ | 4 ГБ, до 50 хостов - 16 ГБ |
| Системный диск | от 38 ГиБ: / 7 ГиБ, /boot 1 ГиБ, /var 30 ГиБ + swap | 55 ГБ + DWH | 50 ГБ + DWH |
| Сеть | 1 Гбит/с; хосту с ролью HostedEngine рекомендуют 2 порта по 10 Гбит/с | 1 Гбит/с | 1 Гбит/с |
Минимум нужен, чтобы платформа запустилась, продуктив на нём держать не стоит. Хост считают от нагрузки:
Пример: 20 ВМ по 8 ГБ, итого 160 ГБ, плюс 16 ГБ на Engine. На трёх хостах по схеме «минус один» каждому нужно 176 / 2 = 88 ГБ под ВМ. С запасом под систему и рост разумно ставить по 128 ГБ на хост. Процессоры в кластере лучше брать одного семейства: живая миграция между разными поколениями CPU упирается в общий для кластера набор инструкций. Подробнее о том, из чего складывается производительность, - в статье про хост-машину в виртуализации.
Перед установкой проверьте BIOS: аппаратная виртуализация и NX должны быть включены, без них хост не сможет запускать виртуальные машины. Где эти настройки у Dell, HPE, Supermicro и других производителей, мы описали в инструкции как включить виртуализацию в BIOS. Ещё два требования zVirt 5.0: Node нельзя ставить на флеш-накопитель, а системный диск размечается стандартными разделами ext4, без LVM. Если на сервере стоит аппаратный RAID-контроллер, соберите зеркало из двух дисков под систему заранее.
Готовые конфигурации под кластер можно подобрать в разделе сервер для виртуализации.
Сеть в zVirt логически делится на несколько назначений, и развести их по портам и VLAN проще до установки, чем переносить работающий кластер.
| Сеть | Для чего | Скорость (наш ориентир) | Замечание |
|---|---|---|---|
| Управление | связь Engine с хостами, портал администрирования | 1 Гбит/с достаточно | задержка от менеджера до хоста не больше 100 мс |
| Хранилище | iSCSI или NFS до СХД | 10 Гбит/с | лучше отдельные порты или VLAN, MTU 9000 при поддержке всей цепочки |
| Миграция ВМ | перенос памяти работающих ВМ между хостами | 10 Гбит/с | на 1 Гбит/с миграция ВМ с большим объёмом памяти идёт долго |
| Сети ВМ | трафик виртуальных машин | по нагрузке | VLAN на портах коммутатора настроить заранее |
| BMC (IPMI, iDRAC, iLO) | удалённое управление и питание серверов | 1 Гбит/с | отдельная сеть, пригодится для управления питанием из Engine |
Вендор требует MTU не меньше 1500 байт и рекомендует 9000 для адаптеров на 25 Гбит/с и выше. Для отказоустойчивости Hosted Engine задержка между хостами не должна превышать 7 мс, то есть все хосты с ролью HostedEngine должны стоять в одной площадке. Как выбрать адаптеры под такой план, разобрано в статье про сетевые карты для виртуализации.
Отдельный подвох: при развёртывании Hosted Engine установщик временно использует локальную сеть из диапазона 192.168.0.0/16. Если ваша сеть управления живёт в 192.168.x.x, сверьте адреса до запуска мастера.
DNS. У Engine и у каждого хоста должно быть полное доменное имя (FQDN), и оно должно разрешаться в обе стороны: записи A в прямой зоне и PTR в обратной. Проверить до установки можно с любой машины в сети управления:
nslookup engine.corp.local - имя должно вернуть IP-адрес
nslookup 10.10.10.10 - адрес должен вернуть то же имя
Если DNS-сервера в компании нет или его роль выполняет роутер, где нельзя завести обратную зону, поднимите полноценный: как это сделать, описано в статье про настройку DNS. В крайнем случае вендор допускает записи в /etc/hosts на всех серверах, но при каждом новом хосте их придётся править везде.
Частая ошибка: DNS и NTP переезжают внутрь нового кластера.
Логичный ход при миграции - перенести все сервисы в zVirt, включая контроллер домена с DNS. После этого кластер зависит от ВМ, которая сама работает в этом кластере. Отключили питание - Engine не находит хосты по именам, а DNS не поднимется, пока не запустится Engine. Держите хотя бы один DNS и источник времени вне кластера: на отдельной небольшой машине или втором контроллере домена на другом железе.
Время. Часы на хостах, СХД и Engine должны совпадать: расхождение ломает проверку сертификатов и путает журналы. Настройте на всех серверах синхронизацию с одним NTP-сервером. У ВМ HostedEngine отдельно проверьте часовой пояс: в публичном разборе миграции команда ITfresh обнаружила, что менеджер по умолчанию работал в UTC, и расписание резервного копирования сдвинулось на три часа.
И последнее: не отключайте IPv6 на ВМ HostedEngine, даже если в сети он не используется. Это прямое требование документации.
Для Hosted Engine нужен отдельный домен хранения под ВМ менеджера, и он должен быть готов до запуска развёртывания: мастер спросит его в процессе. В примере вендора под домен Engine и под первый домен данных выделено по LUN на 100 ГБ на СХД с iSCSI. Держите домен менеджера только под менеджер: рабочие ВМ туда не кладут, чтобы переполнение или проблемы с их дисками не остановили управление всей средой.
Если в офисе нет СХД, а есть сервер с дисками, его можно превратить в NFS-хранилище. Это рабочий вариант для старта, но честно оцените риск: вся среда зависит от одного сервера, и его отказ останавливает и ВМ, и менеджер. Чем iSCSI отличается от NFS и FC по нагрузке и отказоустойчивости, разобрано в статье про протокол iSCSI и другие протоколы доступа к СХД.
Гиперконвергентная схема, где хранилище собирается из дисков самих хостов, в zVirt сейчас строится с программным хранилищем MIND uStor. Это продукт другого разработчика, MIND Software, со своей лицензией и поддержкой, и планировать его нужно отдельным проектом.
Перед окном работ пройдитесь по списку. Пропущенный пункт либо останавливает установку, либо всплывает через месяц работы кластера:
Дальше маршрут без экранов: что делаем, что проверить перед следующим шагом и где подробности у вендора.
nmtui на каждом хосте. Проверка: хосты пингуют друг друга и СХД по именам.dnf repolist all, затем dnf config-manager --enable "zvirt*" и zvirt-credentials.py -u <логин> -p <пароль> с учётными данными из лицензии. Проверка: dnf repolist показывает репозитории zVirt включёнными.Весь маршрут со скриншотами у Orion soft - в той же пошаговой инструкции из начала статьи и в их статье на Хабре.
Резервная копия менеджера. Первую копию снимите в тот же день штатной утилитой, она сохраняет базу и конфигурацию Engine в один файл и не требует остановки службы:
engine-backup --scope=all --mode=backup --file=engine-backup.bck --log=engine-backup.log
Файл сразу унесите с ВМ менеджера на другое хранилище и поставьте такое копирование в расписание. Для Standalone это единственный способ быстро вернуть управление после отказа сервера.
Режимы обслуживания Hosted Engine. Перед обновлением или любыми работами, при которых останавливается служба ovirt-engine, включают глобальный режим обслуживания: агенты высокой доступности перестают следить за ВМ менеджера и не пытаются её перезапустить. Перед обслуживанием отдельного хоста хватит локального режима, ВМ менеджера уедет с него на другой хост.
hosted-engine --set-maintenance --mode=global - глобальный режим
hosted-engine --set-maintenance --mode=local - локальный, на текущем хосте
hosted-engine --set-maintenance --mode=none - выключить обслуживание
Забытый глобальный режим оставляет менеджер без защиты: если хост с ВМ HostedEngine упадёт, никто её не перезапустит. После работ проверьте, что режим снят.
Управление питанием. При добавлении хоста в zVirt можно указать его карту управления питанием, а в кластере настроить политику ограждения (fencing): Engine перезагрузит зависший хост через BMC, чтобы его ВМ безопасно запустились на другом. Если на серверах есть iDRAC, iLO или IPMI, заведите их в сеть управления и пропишите в настройках хостов. Как настроить доступ к контроллеру Dell, описано в статье про iDRAC.
Сертификат и консоль. Импортируйте корневой сертификат менеджера в браузеры администраторов, иначе портал и консоли ВМ будут ругаться на безопасность. В гостевых Linux поставьте qemu-guest-agent и spice-vdagent: с агентом Engine видит IP-адреса ВМ и надёжнее выключает их из портала.
За этим сообщением портала стоит простая вещь: веб-интерфейс открылся, а служба, которая выполняет операции, не отвечает. В zVirt за это отвечают две службы на ВМ или сервере менеджера: ovirt-engine и zvirt-engine-backend. Сначала посмотрите их состояние командой systemctl status zvirt-engine-backend ovirt-engine. В заметках к релизам zVirt при ошибках портала вендор рекомендует перезапуск обеих служб. В схеме Hosted Engine перед этим включите глобальный режим обслуживания, чтобы агенты высокой доступности не перезапустили ВМ менеджера посреди работ, и выключите его после:
systemctl restart zvirt-engine-backend
systemctl restart ovirt-engine
Если после перезапуска ошибка вернулась, ищите причину по таблице:
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| Портал открывается, операции не выполняются | службы не поднялись после перезагрузки или обновления | журнал journalctl -u ovirt-engine и journalctl -u zvirt-engine-backend |
| Служба стартует и падает | закончилось место на диске менеджера | df -h, особенно /var |
| Backend не стартует после установки без DWH | известная ошибка, её исправляли в обновлениях | версия zVirt и заметки к релизу, обновление до актуальной |
| ВМ HostedEngine не запускается | недоступен домен хранения менеджера или хосты не видят СХД | hosted-engine --vm-status на хосте, доступность LUN или NFS |
| Портал не открывается по имени, хосты не подключаются | DNS или время | разрешение FQDN в обе стороны, синхронизация NTP |
| Ошибки после смены имени менеджера | привязка сертификатов и SSO к старому FQDN | раздел «Решение проблем» в вики Orion soft |
Отдельные разборы вроде «не запускается ВМ Hosted Engine из-за службы vdsm» или ошибок при добавлении хоста собраны в базе решений Orion soft. Если среда в продуктиве и причина не очевидна, не экспериментируйте с базой менеджера: сначала резервная копия, потом обращение в поддержку.
Да. Два хоста с ролью HostedEngine дают отказоустойчивость менеджера, но на время обслуживания одного сервера второй остаётся без резерва. Ресурсы нужно считать так, чтобы один хост тянул всю нагрузку.
Развернуть можно на одном, для отказоустойчивости менеджера нужно минимум два хоста с ролью HostedEngine, максимум таких хостов в одной установке - семь. Остальные хосты кластера добавляются обычными.
zVirt лицензируется на физический сервер виртуализации с двумя процессорами. Отдельной лицензии на менеджер управления в прайсе нет. Актуальные условия уточняйте у Orion soft или партнёра на момент закупки.
zVirt поставляется загрузочным ISO-образом zVirt Node. Учётные данные для репозиториев Orion soft выдаёт при покупке лицензии, без них хост не получит пакеты. За тестовой версией обращаются к вендору или его партнёру.
В 5.0 хосты работают на новой ОС zVirt Node 2.0, а системный диск размечается стандартными разделами ext4 без LVM. Скриншоты и разметку из старых инструкций под 4.x не переносите, сверяйтесь с документацией нужной версии: у вики Orion soft есть переключатель версий.
По теме: живая миграция виртуальных машин · SAN для среднего предприятия
Планируете кластер на zVirt?
Инженеры ITTELO подберут серверы и СХД под вашу нагрузку и схему развёртывания, соберут и протестируют оборудование перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
