Стрелка миграции с 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 РМ

Заменили 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: экономика, а не идеология

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

Broadcom купил VMware в ноябре 2023-го и, не теряя времени, за 18 месяцев пересадил всех клиентов с привычных perpetual-лицензий на подписку. И тут началось самое интересное: цена взлетела! Если раньше это было примерно 850 долларов за CPU-сокет в год, то теперь — 1500-2300 долларов, в зависимости от выбранного пакета. Вторая головная боль — наши российские реселлеры VMware просто физически не могут отгружать новые лицензии, а старые перестают обновляться через личный кабинет VMware Customer Connect. Ну и вишенка на торте — патчи. Представьте, в марте 2025-го в ESXi обнаружили серьёзную уязвимость CVE-2025-22224, которая позволяла совершить побег из 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-сеть, и адреса не были жёстко привязаны к гипервизору. Но должен отметить, это особый случай. Обычно, когда я планирую миграцию, всегда закладываю окно простоя именно из-за возможной смены IP-адресов.

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

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

Комплект из трёх Dell R650 обошёлся в 6.8 млн ₽ на момент закупки в феврале 2026 года. Мы брали его через российского интегратора с трёхлетней расширенной гарантией 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 официально, на момент 2026 года, не поддерживает zVirt как гипервизор-источник для image-level бэкапа. Но есть выход: 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 млн на лицензиях, а сам проект окупился всего за пять месяцев. Кстати, если у вас уже есть подходящее железо (три хоста с 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

Похожие статьи

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.