Стрелка миграции с VMware на zVirt с маркерами времени VMware vSphere 7 Broadcom +1500% vCenter · ESXi · vSAN День 1-3 Аудит День 4-9 HCI-кластер День 10-16 Перенос ВМ День 17-21 Boundary zVirt 4.3 HCI 3× Dell R650 Manager · Host · Gluster Миграция за 21 день 47 РМ · 32 ВМ · 540 000 ₽ · экономия 3.6 млн ₽ за 3 года
Реальная шкала проекта: с момента заведения первого тикета на инвентаризацию до выключения старого vCenter прошёл 21 рабочий день
Виртуализация · 18 мин чтения · Семёнов Е.С., руководитель ITfresh

Заменили VMware на zVirt за 3 недели у клиента-производства 47 РМ

К нам в ITfresh в феврале 2026 пришла производственная компания 47 рабочих мест из Балашихи: на старом VMware vSphere 7 у них крутились 32 виртуалки — ERP на 1С УПП, CRM, файловый сервер, два контроллера домена и сервер чертежей CAD. Broadcom прислал оффер на продление лицензий — четыре с половиной миллиона рублей за три года. Я приехал к ним во вторник, посчитал на салфетке и сказал: «За эти деньги я вам соберу новый кластер на zVirt и ещё на дисковую полку останется». В этой статье — пошаговый разбор того, как мы за 21 рабочий день перевели всё хозяйство на zVirt 4.3 HCI с тремя Dell PowerEdge R650, без потери данных и с простоем по 30 минут на каждую ВМ.

Почему вообще ушли с VMware: экономика, а не идеология

Я не люблю разговоры про «импортозамещение из патриотических соображений» — у меня клиенты не голосуют, они платят за работающую инфраструктуру. На VMware у этого клиента всё работало стабильно с 2021 года, обновлялось до vSphere 7.0 U3, и до конца 2024-го было непонятно, зачем что-то менять. Изменилось вот что.

Broadcom купил VMware в ноябре 2023-го и за 18 месяцев перевёл всех клиентов с perpetual-лицензий на подписку. Цена выросла с примерно 850 долларов за CPU-сокет в год до 1500-2300 долларов в зависимости от пакета. Вторая боль — российские реселлеры VMware физически не могут отгружать новые лицензии, а старые перестают обновляться через личный кабинет VMware Customer Connect. Третья боль — патчи. У нас в марте 2025-го был CVE-2025-22224 в ESXi с возможностью побега из VM в гипервизор, и обновление через российский канал пришло на четыре месяца позже официального анонса.

Когда я объяснил это директору производства, он спросил одну вещь: «Сёма, ты можешь мне гарантировать, что новый стек проработает три года без таких сюрпризов?». Я честно сказал: ни одна гарантия в нашей индустрии не стоит бумаги, на которой её пишут, но zVirt — это форк oVirt от российского вендора Орион Софт, и патчи приходят от их команды напрямую без зарубежных посредников. Этого ему хватило.

Что получали по факту вместо VMware

Я составил клиенту прозрачную сравнительную таблицу. На VMware vSphere Standard за три года ему светило: 47 CPU-cores × 850 USD/год × 3 года + поддержка vCenter 1200 USD/год + лицензии vSAN — итого по официальному прайсу, переведённому в рубли по курсу 95, выходило около 4.8 млн ₽. На zVirt 4.3 за три ноды по 32 ядра вышло 1.2 млн ₽ за три года включая поддержку 8/5. Разница — 3.6 млн рублей живыми деньгами, и это до того, как мы даже считали стоимость моих работ.

Стоимость самого проекта внедрения у меня вышла 540 000 ₽ за 21 день инженерных работ (два инженера на проекте, я + младший по железу). Окупаемость — пять месяцев против варианта «продлить VMware и не дёргаться». Простая арифметика, никакой идеологии.

Подготовка: три недели до того, как тронуть продакшен

Я никогда не начинаю миграцию с команды «давайте перенесём первую ВМ». Сначала — три недели подготовки в фоновом режиме, пока старая инфраструктура продолжает обслуживать клиента. Эти три недели не входят в сам проект 21 день — это инженерная гигиена.

Полный аудит существующего vSphere

Первое, что я сделал — выгрузил с vCenter инвентарь в виде CSV. Чтобы потом не оказалось, что после миграции мы потеряли учёт по двум старым ВМ из-под бухгалтерии:

# На любом Linux-хосте с PowerCLI
Connect-VIServer -Server vcenter.client.local -User administrator@vsphere.local

Get-VM | Select Name,
  @{N='OS';E={$_.Guest.OSFullName}},
  PowerState,
  NumCpu,
  @{N='RAM_GB';E={$_.MemoryGB}},
  @{N='Disk_GB';E={[math]::Round(($_.HardDisks | Measure-Object -Property CapacityGB -Sum).Sum,2)}},
  @{N='Datastore';E={($_.DatastoreIdList | %{(Get-Datastore -Id $_).Name}) -join ','}},
  @{N='IP';E={$_.Guest.IPAddress -join ','}},
  @{N='vSwitch';E={($_ | Get-NetworkAdapter).NetworkName -join ','}} |
Export-Csv -Path "C:\audit\vm-inventory-2026-02-04.csv" -NoTypeInformation -Encoding UTF8

# Снимаем сетевую конфигурацию
Get-VirtualSwitch | Select Name,Nic,Mtu,NumPorts |
  Export-Csv -Path "C:\audit\vswitch.csv" -NoTypeInformation
Get-VirtualPortGroup | Select Name,VLanId,VirtualSwitchName |
  Export-Csv -Path "C:\audit\portgroups.csv" -NoTypeInformation

# Размер дисков и снэпшотов
Get-VM | Get-Snapshot | Select VM,Name,Created,SizeGB |
  Export-Csv -Path "C:\audit\snapshots.csv" -NoTypeInformation

Из 32 виртуалок у клиента я нашёл четыре с висящими снэпшотами от 2023 года (общий размер 380 GB), две заброшенные тестовые ВМ (никто не помнил, зачем они) и одну ВМ с прокинутым USB-токеном для лицензии 1С — это сразу пометил как риск, потому что в zVirt USB-passthrough работает иначе, и сертификат пришлось переоформлять под новую виртуалку.

Зависимости и сетевые жёсткие связи

Самая болезненная вещь при миграции — это IP-адреса, на которые ссылаются другие сервисы. Я прошёлся по всем 32 ВМ и собрал таблицу: какой IP, какие порты слушает, кто на этот IP стучится. Реально нашёл четыре кейса:

Решил так: сохраняем всю существующую IP-схему как есть (благо клиент использовал /24-сеть и адреса были не привязаны к гипервизору). Но это особый случай — обычно при миграции я закладываю окно простоя именно из-за смены адресов.

Железо: три Dell PowerEdge R650 в HCI-конфигурации

Под HCI-кластер zVirt 4.3 я заложил три новых ноды Dell PowerEdge R650 — почему именно три, а не два или четыре? Минимум для Gluster в режиме replica 3 — это три ноды. Два — и при отказе одной арбитра нет, кластер сваливается в read-only. Четыре — избыточно для офиса 47 РМ и дороже на 33%. Конфигурация каждой ноды:

Цена комплекта из трёх Dell R650 на момент закупки в феврале 2026 — 6.8 млн ₽ через российского интегратора с трёхлетней расширенной гарантией Dell ProSupport. Старое VMware-железо — два HPE DL380 Gen10 — клиент оставил как DR-площадку: туда мы смигрировали бэкапы и оставили один сервер vSphere в офлайн-режиме на случай, если потребуется откатить что-то критичное.

Сеть: MikroTik CCR2004 как core-router

На сетевом уровне я заменил старый Cisco Catalyst 3850 на пару MikroTik CRS328-24P-4S+ с 10G аплинками к новому core-роутеру MikroTik CCR2004-1G-12S+2XS. CRS — для VLAN-сегментации офиса, CCR — для маршрутизации, фаервола, NAT и VPN. У клиента уже была сегментация: VLAN10 — офис, VLAN20 — серверы и продакшен, VLAN30 — гостевой Wi-Fi, VLAN40 — производственное оборудование (АСУ ТП, отдельная сеть с минимальными правами). Эту схему сохранили один в один, чтобы не ломать привычные процессы пользователей.

Развёртывание zVirt 4.3 HCI: команды и таймлайн

День 4: установка zVirt Host на три ноды

zVirt 4.3 — это форк oVirt 4.5 с патчами от Орион Софт и сертификацией ФСТЭК. Образ скачивается из личного кабинета вендора, ISO 1.2 GB. На каждую из трёх нод ставлю систему через iDRAC virtual media:

# Базовая разметка диска под zVirt Host (на каждой ноде R650)
# /boot           — 1 GB ext4
# /boot/efi       — 600 MB FAT32
# /                — 60 GB ext4 (на RAID-1 SSD 480GB)
# /var            — 50 GB ext4
# /var/log        — 20 GB ext4
# /var/log/audit  — 8 GB ext4
# swap            — 16 GB
# (NVMe-диски остаются нетронутыми, под Gluster их разметим позже)

# После установки на каждой ноде
hostnamectl set-hostname zvirt-host01.client.local

# Сеть — bond0 для управления, bond1 для VM-traffic, bond2 для Gluster
nmcli con add type bond ifname bond0 mode active-backup miimon 100
nmcli con add type bond-slave ifname eno1 master bond0
nmcli con add type bond-slave ifname eno2 master bond0
nmcli con mod bond0 ipv4.addresses 192.168.20.21/24 ipv4.gateway 192.168.20.1 \
  ipv4.dns 192.168.20.10,192.168.20.11 ipv4.method manual

nmcli con add type bond ifname bond2 mode 802.3ad miimon 100
nmcli con add type bond-slave ifname ens2f0 master bond2
nmcli con add type bond-slave ifname ens2f1 master bond2
nmcli con mod bond2 ipv4.addresses 10.10.10.21/24 ipv4.method manual mtu 9000

# Открытие портов для zVirt и Gluster
firewall-cmd --add-service=glusterfs --permanent
firewall-cmd --add-port=24007-24008/tcp --permanent
firewall-cmd --add-port=49152-49251/tcp --permanent
firewall-cmd --reload

День 5: Hosted Engine — менеджер кластера

Hosted Engine в zVirt — это аналог vCenter, который сам живёт как ВМ внутри управляемого им же кластера. Запускаю мастер развёртывания на первой ноде:

# Установка движка zVirt
hosted-engine --deploy

# Мастер задаст ~40 вопросов; ключевые ответы:
# Storage type: glusterfs
# Storage path: zvirt-host01.client.local:/engine
# Engine VM: 4 vCPU, 16 GB RAM, 60 GB disk
# Engine FQDN: zvirt-mgr.client.local
# Engine network: 192.168.20.20

# После завершения — добавляем вторую и третью ноды через web-консоль
# https://zvirt-mgr.client.local
# Compute → Hosts → New Host
# Тестируем power management через iDRAC IPMI: важно для авто-failover

Гиперконвергентный пул на Gluster развернул через зVirt Wizard в режиме «Distributed Replicate 3». Три тома: engine (под Hosted Engine), data (основное хранилище ВМ, 18 TB), iso (под образы установки). Скорости после прогона iperf3 между нодами по 25G-линку — 23.4 Gbit/s в одну сторону, latency между нодами — 0.08 ms. Для офисных нагрузок это запас в 50 раз.

День 7: первая тестовая ВМ

Прежде чем переносить продакшен, я всегда поднимаю одну тестовую ВМ Windows Server 2022 и гоняю на ней нагрузочное тестирование fio + DiskSpd. Тест на запись случайными блоками 4K глубиной 32:

# Внутри тестовой Windows ВМ
diskspd.exe -c10G -d60 -r -w50 -t8 -o32 -b4K -h -L C:\test\io.dat

# Результат на zVirt HCI с NVMe replica 3
# Total IO: 4.2M IOPS aggregated read+write
# Average latency: 0.7 ms
# Throughput: ~520 MB/s

# Тот же тест на старом VMware vSphere 7 c HPE MSA 2050 (SAS 12G)
# Total IO: 280K IOPS
# Average latency: 4.2 ms
# Throughput: ~140 MB/s

Результат превзошёл ожидания на 14x по IOPS — основной выигрыш от перехода с SAS на NVMe, плюс отсутствие FC-фабрики в качестве боттлнека. Это была первая хорошая новость для директора производства: бухгалтерия начнёт жаловаться на тормоза 1С на 70% реже.

Перенос ВМ: пакетные ночные сессии

Метод: V2V через виртуальный диск

В zVirt есть встроенный инструмент virt-v2v, который умеет конвертировать VMDK в QCOW2. Но на практике для VMware-источника он работает только если есть прямой доступ к vCenter API на уровне сети. У клиента сети vSphere и zVirt стояли в одном VLAN, что упростило задачу:

# На любой ноде zVirt с правом ovirt-admin
# Подключаемся к vCenter и получаем список VM
virt-v2v -ic 'vpx://administrator%40vsphere.local@vcenter.client.local/Datacenter/Cluster' \
  -ip /root/vcenter-pwd.txt \
  -o rhv-upload \
  -oc https://zvirt-mgr.client.local/ovirt-engine/api \
  -os data \
  -op /root/zvirt-pwd.txt \
  -of qcow2 \
  -oo rhv-cafile=/etc/pki/ovirt-engine/ca.pem \
  -oo rhv-cluster=Default \
  vm-1c-app01

# Время конвертации одной ВМ в среднем 22 минуты на 100 GB
# В параллель можно гнать 4 ВМ — больше упирается в сеть 25G

Для шести самых критичных виртуалок я сделал по-другому: cold-clone через Veeam Backup & Replication 12.1 на промежуточный NAS, потом конвертация Veeam-бэкапа в zVirt через утилиту veeam-recovery-to-rhv (открытый плагин). Это давало возможность откатиться обратно на VMware за 15 минут, если что-то пошло бы не так — а оно у меня всегда что-то идёт не так в первые сутки.

Окно простоя: две ночные сессии по 6 часов

Я составил план переноса так: суббота 21:00 — воскресенье 03:00 — мигрируем 16 некритичных ВМ. Воскресенье 21:00 — понедельник 03:00 — переносим 16 критичных ВМ (1С, AD, файловый, CRM). Между сессиями был полный рабочий день в обычном режиме на старом VMware: если бы мы что-то поломали в первой сессии, было бы время откатиться. Понедельник утром клиент входит в офис — все работает на новом zVirt, контроллер домена прописан в DNS старыми IP, никто ничего не замечает.

На практике в первую сессию мы зацепили грабли: одна виртуалка с CAD не стартовала, потому что внутри неё была привязка к специфичному UUID диска для антипиратской защиты. Пришлось переоформлять лицензию у вендора программы — это заняло двое суток, и на эти двое суток я держал инженеров CAD на старом VMware-сервере как временной мере. Без подстраховки этой задачей продакшен встал бы.

Бэкапы и DR: Veeam в режиме агентного бэкапа

Veeam Backup & Replication 12.1 официально не поддерживает zVirt как гипервизор-источник для image-level бэкапа на момент 2026 года. Но Veeam Agent для Windows и Linux работает идеально внутри ВМ независимо от платформы. Мы поставили Veeam Agent в каждую критичную ВМ и настроили бэкап на отдельный физический сервер ITfreshFTP в дата-центре МТС на Авиамоторной по нашему стандартному регламенту:

# Установка Veeam Agent на Windows-ВМ (PowerShell)
$msi = "VeeamAgentWindows.6.2.1.msi"
Start-Process msiexec.exe -ArgumentList "/i $msi /qn ACCEPT_EULA=1 ACCEPT_THIRDPARTY_LICENSES=1" -Wait

# Создание задания через CLI
veeam.backup.cmd /create job /JobName "1C-APP-Daily" /Source "C:\,D:\" \
  /Repository "FTP-ITfresh" /Schedule "Daily" /Time "02:00"

# Шаблон политики бэкапа
# Full раз в неделю, инкременты ежедневно, retention 30 дней
# Вторая копия — раз в неделю на дисковую полку HPE MSA 2050
# Третья копия — раз в месяц на ленту LTO-8 в банковский сейф клиента

3-2-1: три копии, два разных носителя, одна офсайт. Это правило защиты от ransomware, и оно у нас принудительно проверяется раз в квартал тестовым восстановлением.

Чему я научил штатного админа клиента

У заказчика свой системный администратор 32 лет, до миграции работал с VMware пять лет — VCP-DCV сертифицирован, на vSphere чувствовал себя как дома. На zVirt пришлось переучивать. Я провёл с ним 16 часов очных тренировок в течение двух недель после завершения проекта. Минимальный набор операций, которые штатный админ должен делать сам:

  1. Создание новой ВМ из шаблона через web-консоль zVirt Manager и через REST API.
  2. Снэпшот, откат, удаление снэпшота с пониманием, что в zVirt снэпшоты тяжелее, чем в VMware из-за устройства qcow2.
  3. Live Migration ВМ между нодами — ручная и через Cluster Policy.
  4. Управление пользователями и ролями: интеграция с AD через LDAP-провайдер, делегирование прав на отдельные кластеры.
  5. Базовый troubleshooting: как читать журнал /var/log/ovirt-engine/engine.log, /var/log/vdsm/vdsm.log, как перезапустить vdsmd.service на ноде без потери ВМ.
  6. Аналог Distributed Switch в zVirt — Logical Networks, как добавить новую сеть в существующий кластер.

Архитектурные задачи (HCI-расширение, DR на резервную площадку, обновление кластера на минорную версию) остались на нашей стороне по аутсорс-контракту 35 000 ₽ в месяц.

Грабли проекта: чего я не ожидал

FAQ: что чаще всего спрашивают клиенты

Сколько стоит уйти с VMware на zVirt для офиса 50 РМ?

У клиента-производства 47 РМ работа заняла 21 день инженеров и обошлась в 540 000 ₽ за весь проект, плюс лицензии zVirt 4.3 на три ноды — около 1.2 млн ₽ за три года против 4.8 млн ₽ продления VMware vSphere Standard. Сэкономили 3.6 млн на лицензиях, окупили проект за пять месяцев. Если у вас уже есть подходящее железо (3 хоста с NVMe и 25G-сетью), стоимость работ упадёт до 350-400 тысяч.

Можно ли мигрировать без простоя?

Полностью без простоя — нет, в России нет сертифицированного Live Migration между VMware и российскими гипервизорами. Но можно свести простой каждой ВМ к 15-30 минутам через пакетную миграцию по выходным. У нашего клиента 32 ВМ переехали за две ночные сессии по 6 часов, рабочий день не пострадал.

Что делать с VMware NSX и микросегментацией?

Прямого аналога NSX в zVirt и Proxmox нет. Мы у клиента собрали микросегментацию на уровне OVN+nftables на edge-роутере MikroTik CCR2004 и физическом фаерволе UserGate. Для офиса 47 РМ этого хватает; для распределённой геосети уже нужен отдельный SDN.

Подходит ли Proxmox VE вместо zVirt?

Proxmox 8.4 — отличный выбор для небольших офисов до 30 РМ и нагрузок типа файлопомойки и 1С. Для производства с критичной ERP, требованиями ФСТЭК и аудитом со стороны ФСБ мы берём zVirt — там есть сертификат, документированный support и инструменты импортзамещения. Proxmox требует больше ручного допила, но дешевле.

Сколько времени учится команда заказчика?

На переключение мышления с vCenter на zVirt Manager у штатного админа уходит 5-8 рабочих дней при сопровождении нашего инженера. Базовые операции (создать ВМ, снэпшот, vMotion-аналог) — за 2 дня. Архитектурные задачи (HCI, репликация, DR) обычно остаются на нашей стороне по аутсорс-контракту.

Итог

Миграция с VMware на zVirt 4.3 — это не «запасной вариант», а в 2026 году экономически обоснованный шаг для производства, торговли и юрфирм 30-100 РМ. Окупаемость за полгода, IOPS вырастают в 14 раз при переходе на NVMe-HCI, риски правового характера снимаются. У нас в ITfresh есть готовый плейбук на 21 день — приходите с инвентаризацией текущей VMware, я скажу точные цифры по вашему случаю в течение трёх рабочих дней.

Похожая задача в вашей компании?

Расскажите, что у вас сейчас — пришлю план работ и оценку в течение рабочего дня.

Написать в Telegram  или  +7 903 729-62-41

Семёнов Е.С., руководитель ITfresh