25 лет VMware и наша стратегия миграции 4 клиентов в 2026

Вы не поверите, но у меня до сих пор хранится коробка с VMware Workstation 4.5! Я купил её ещё в далёком 2004-м году за 199 долларов, и именно на ней я поднимал свои самые первые тестовые лабы. За эти 25 лет VMware просто перевернула всю индустрию: они создали такие вещи, как vMotion, DRS, vSAN, NSX. Каждый из этих терминов стал, по сути, азбукой для любого системного администратора. И вот, в 2025-2026 годах к нам в ITfresh обратились сразу четыре клиента с одним и тем же вопросом: «Что нам теперь делать с VMware?» Каждому из них я предложил своё решение. В этой статье я поделюсь нашей стратегией миграции с VMware на различные альтернативные стеки. Выбор зависит от типа бизнеса и конкретных нагрузок. Никакой воды, только факты и чёткие цифры по каждому из наших четырёх проектов.

Почему миграция стала неизбежной даже для лояльных клиентов

Мне вся эта история до сих пор напоминает старую добрую сказку про «золотой век, который больше никогда не вернётся». В 2010-е годы VMware vSphere был абсолютным синонимом виртуализации в корпоративном сегменте. У нас, в России, доля этой платформы достигала аж 79%! Представьте, каждый сервер у каждого нашего клиента тогда крутил ESXi, в каждой стойке обязательно стоял vCenter, а на каждых выходных админы гоняли vMotion. Но эта идиллия рухнула всего за три этапа.

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

Второе событие произошло в ноябре 2023-го. Broadcom купил VMware за гигантские 61 миллиард долларов. И уже с первого квартала 2024-го они начали переводить весь мир на подписочную модель, при этом безжалостно зарезав 80% продуктового портфеля. Такие продукты, как vSphere Standalone, vSphere Essentials Plus, Workspace ONE – всё это либо исчезло, либо было запихнуто в дорогущие бандлы, например, VCF (VMware Cloud Foundation).

А третье событие развернулось в 2024-2025 годах. Тут к нам подкрались критические уязвимости в vCenter и ESXi (это CVE-2024-37085, CVE-2025-22224, CVE-2025-22225) и, как назло, патчи для российских клиентов стали приходить с огромной задержкой. Когда наш бывший партнёр-реселлер просто перестал отвечать на письма, моим клиентам пришлось самостоятельно закрывать эти дыры, используя всякие «хаки».

На фоне всего этого безобразия осенью 2025-го сразу четыре наших клиента одновременно мне заявили: «Сёма, пора мигрировать!» И тогда я чётко осознал: одного-единственного универсального плана тут не существует.

Принцип «один гипервизор не на всех»

Знаете, в нашей индустрии часто любят продавать гипервизор как некий универсальный молоток – мол, ставьте Proxmox, zVirt или что-угодно ещё куда попало. Я считаю, что это вредное упрощение. У любого бизнеса свои требования: кому-то критичен сертификат ФСТЭК, кому-то подавай всю экосистему Microsoft, а кто-то готов на всё, лишь бы минимизировать лицензионные расходы. Поэтому для каждого из этих четырёх клиентов я подбирал стек строго индивидуально.

Если бы я мог донести до владельца бизнеса всего одну мысль на этой странице, то она была бы такой: самый дешёвый гипервизор в итоге может обойтись вам дороже самого дорогого, если он не вписывается в ваши процессы. Сначала думаем о бизнесе, а уже потом – выбираем стек.

Матрица выбора, которую я использую

• Производство, ERP, требования ФСТЭК: zVirt 4.3 HCI. Сертификат, патчи через российский канал, документированный support.
• Юрфирма, бухгалтерия, файловые сервисы 1С: Proxmox VE 8.4. Дёшево, стабильно, есть community и наша внутренняя экспертиза.
• Торговая компания на Microsoft 365 + RDS + AD: Hyper-V Server 2022. Нативная интеграция со стеком Microsoft, уже оплаченные лицензии Windows Server.
• Госзаказчик, медицина, 152-ФЗ персональные данные класса УЗ-2: Astra Linux Брест 1.7 + KVM. Сертификаты ФСТЭК уровня СВТ-3, реестр Минцифры.

Кейс 1. Производственная компания 47 РМ → zVirt 4.3 HCI

Наш первый проект стартовал в феврале 2026-го. Это была производственная компания из Балашихи, у них цех плюс офис. Основная нагрузка приходилась на 1С УПП 8.3 для 50 одновременных пользователей, инженерное ПО CAD крутилось на терминальном сервере, плюс две виртуальные АТС и контроллеры домена. У этого клиента был отдельный аудит ФСТЭК класса К3, и это моментально отсекло Proxmox, потому что у него нет российского сертификата на сам гипервизор, и Hyper-V, который по своей сути импортный.

В итоге мы выбрали zVirt 4.3 HCI, развернув его на трёх Dell PowerEdge R650. Вся установка заняла всего 21 рабочий день. За три года клиент сэкономил 3.6 млн ₽ по сравнению с VMware. А ещё IOPS у них выросли в целых 14 раз! Это произошло благодаря тому, что мы перешли с SAS-полки HPE MSA 2050 на NVMe в HCI. Мы использовали инструмент V2V, провели две ночные сессии переноса и столкнулись с четырьмя «граблями»: это USB-токен 1С, sparse-конвертация qcow2, часовая зона и SPICE-консоль. Подробно этот кейс я уже описывал в другой статье, здесь же просто делюсь итогом.

Кейс 2. Юрфирма 38 РМ → Proxmox VE 8.4

Следующий клиент – юридическая фирма из ЦАО. Они специализируются на арбитраже и корпоративном праве. У них в работе 1С:Документооборот на 38 пользователей, файловый сервер с огромным архивом дел объёмом 4.2 TB, Active Directory, виртуальный сервер «Контур.Эльба», два контроллера и сервер CRM Bitrix24 self-hosted. Их старая инфраструктура состояла из двух HPE DL380 Gen10 с прямым подключением к дисковой полке HPE MSA 2052 по SAS 12G, и всё это работало под VMware vSphere Essentials Plus.

У этого клиента лицензии Essentials Plus должны были закончиться уже в апреле 2026-го. А Broadcom, как вы помните, уже не продавал перпетуальный пакет для малого бизнеса. Единственный вариант – VCF за 4.5 миллиона рублей в год. Для юрфирмы с 38 рабочими местами это просто неподъёмная сумма! Идеологических требований по ФСТЭК у них не было, поэтому я без колебаний выбрал Proxmox VE 8.4 как самый экономичный и при этом хорошо поддерживаемый вариант.

Конфигурация и развёртывание Proxmox-кластера

Я установил кластер из трёх нод Proxmox 8.4 прямо на существующее железо клиента: это были два HPE DL380 Gen10, к которым мы добавили новую третью ноду Lenovo SR650 V3. Для хранилища выбрали Ceph 18 Reef в режиме 3-репликации, с четырьмя NVMe-дисками по 3.84 TB на каждую ноду. Сеть была организована так: 2× 10G для VM-traffic и 2× 25G для Ceph-public и Ceph-cluster.

# Базовая установка Proxmox 8.4 — установщик, всё штатно
# После установки на каждой ноде поднимаем кластер
pvecm create juridical-cluster -link0 192.168.21.21,priority=1 -link1 10.10.21.21,priority=2

# На второй и третьей нодах
pvecm add 192.168.21.21 -link0 192.168.21.22,priority=1 -link1 10.10.21.22,priority=2

# Установка Ceph
pveceph install --repository enterprise
pveceph init --network 10.10.21.0/24

# Создание мониторов на всех трёх нодах
pveceph mon create
# Через GUI на каждой ноде Datacenter → Ceph → Monitor → Create

# Добавление NVMe-дисков как OSD
for disk in /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1; do
  pveceph osd create $disk
done

# Создание pool
pveceph pool create vmstore --size 3 --min_size 2 --pg_num 256 --add_storages

Через две недели у клиента работал полнофункциональный кластер с HA, Live Migration, snapshot-ами и встроенным резервным копированием через Proxmox Backup Server на отдельный физический сервер с 12-дисковой полкой 12× 16 TB SATA — суммарной полезной ёмкостью 144 TB после учёта чётности.

Перенос ВМ через Veeam-плагин и qemu-img

Для юрфирмы мы применили смешанный подход: критичные ВМ переносили через Veeam Backup 12.1 (то есть, делали бэкап на VMware, а затем восстанавливали на Proxmox с помощью open-source плагина veeam-prox), а вот некритичные — переводили вручную через конвертацию VMDK → qcow2 на промежуточном NAS Synology RS3621xs+.

# Экспорт ВМ из vSphere в OVA
ovftool --acceptAllEulas --noSSLVerify --diskMode=thin \
  vi://administrator@vsphere.local@vcenter.client.local/Datacenter/vm/vm-1c-doc \
  /mnt/transfer/vm-1c-doc.ova

# На Proxmox-ноде
tar -xf vm-1c-doc.ova -C /mnt/pve/transfer/
qemu-img convert -p -O qcow2 /mnt/pve/transfer/vm-1c-doc-disk1.vmdk \
  /var/lib/vz/images/100/vm-100-disk-0.qcow2

# Создание ВМ в Proxmox
qm create 100 --name vm-1c-doc --memory 16384 --cores 8 --net0 virtio,bridge=vmbr0,tag=20 \
  --bootdisk scsi0 --ostype win11 --machine q35
qm set 100 --scsi0 vmstore:0,import-from=/var/lib/vz/images/100/vm-100-disk-0.qcow2
qm set 100 --boot order=scsi0;ide2

# Установка virtio-драйверов внутри Windows ВМ — критично для нормальной работы дисков и сети

Бюджет проекта — 380 000 ₽ за работу инженеров (16 рабочих дней), плюс 220 000 ₽ за подписку Proxmox Enterprise repository на 5 лет (для трёх нод). Итого 600 тысяч против миллионных VMware-сценариев. Клиент остался очень доволен.

Кейс 3. Торговая компания 28 РМ → Hyper-V 2022

Ещё был кейс с торговой компанией, которая занимается оптовой продажей сантехники. У них склад в Подольске и офис в Москве. Их главная особенность: 100% инфраструктуры завязано на Microsoft. Это Active Directory, Office 365 Hybrid с локальным Exchange 2019, RDS-ферма для удалённых сотрудников, файловый сервер DFS и SQL Server 2022 для 1С УТ. У клиента уже были Datacenter-лицензии Windows Server 2022 на два физических хоста, а это даёт право на неограниченное количество виртуальных машин Windows на этих хостах.

Логичный выбор — Hyper-V Server 2022, причём именно встроенная роль в Windows Server Datacenter, а не бесплатный Hyper-V Server 2019 (который Microsoft перестала развивать). Дополнительные плюсы: Failover Cluster Manager, Cluster Shared Volumes, Hyper-V Replica для DR. Все эти возможности уже включены в Datacenter-лицензию, ничего докупать не надо.

Развёртывание Failover Cluster на двух нодах

# На обоих нодах HV01 и HV02 (Windows Server 2022 Datacenter)
Install-WindowsFeature -Name Hyper-V,Failover-Clustering,Multipath-IO,Data-Center-Bridging `
  -IncludeManagementTools -Restart

# После перезагрузки — настройка iSCSI к существующей дисковой полке HPE MSA 2052
# (полку оставили со старого VMware, она ещё в гарантии до 2027-го)
Set-Service -Name MSiSCSI -StartupType Automatic
Start-Service MSiSCSI
New-IscsiTargetPortal -TargetPortalAddress 192.168.30.10 -InitiatorPortalAddress 192.168.30.21
Connect-IscsiTarget -NodeAddress "iqn.1986-03.com.hpe:storage.msa2052..." -IsPersistent $true `
  -IsMultipathEnabled $true

# Включаем MPIO
Enable-MSDSMAutomaticClaim -BusType iSCSI
Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

# Создание кластера
Test-Cluster -Node HV01,HV02 -Include "Inventory","Network","Storage","System Configuration"
New-Cluster -Name SALES-HV-CLUSTER -Node HV01,HV02 -StaticAddress 192.168.30.30 -NoStorage

# Добавление CSV (Cluster Shared Volume)
Get-ClusterAvailableDisk | Add-ClusterDisk
Add-ClusterSharedVolume -Name "Cluster Disk 1"
# Том становится доступен как C:\ClusterStorage\Volume1 на обеих нодах

Перенос ВМ через MVMC и StarWind V2V Converter

Microsoft Virtual Machine Converter (MVMC) официально не поддерживает миграцию с vSphere 7.0+, но StarWind V2V Converter работает на пятёрку. Использовал его для конвертации VMDK → VHDX:

# Установка StarWind V2V Converter (бесплатная редакция)
# На отдельной windows-машине-конвертере подключаем VMDK-файлы из vSphere через ovftool

ovftool vi://administrator@vsphere.local@vcenter.local/Datacenter/vm/sales-1c-app \
  C:\transfer\sales-1c-app.ovf

# Запускаем StarWind V2V Converter, выбираем VMDK → VHDX, target = Hyper-V Server 2022
# Плюс конвертора: умеет добавлять virtio в VHDX по пути

# В Hyper-V Manager импорт ВМ из VHDX
New-VM -Name "SALES-1C-APP" -MemoryStartupBytes 32GB -SwitchName "vSwitch-VM" `
  -Generation 2 -Path "C:\ClusterStorage\Volume1\VMs"
Add-VMHardDiskDrive -VMName "SALES-1C-APP" -Path "C:\ClusterStorage\Volume1\VMs\SALES-1C-APP\disk0.vhdx"
Set-VMProcessor -VMName "SALES-1C-APP" -Count 8
Set-VM -Name "SALES-1C-APP" -AutomaticStartAction Start -AutomaticStopAction Save

Бюджет проекта — 290 000 ₽ за работу (12 рабочих дней), всё остальное — уже оплаченные лицензии Microsoft. Это самый дешёвый вариант миграции из четырёх кейсов, поскольку лицензионная база была на 100% готова заранее.

Кейс 4. Медклиника 22 РМ → Astra Linux Брест 1.7

А вот медицинская клиника на Тверской. У них 22 рабочих места, специализация — стоматология и косметология премиум-сегмента. Главная проблема — это, конечно, 152-ФЗ и персональные данные категории «специальные», то есть медицинские сведения. Тут ещё и требования ФСТЭК класса К1, плюс обязательная аттестация информационных систем персональных данных. Поверьте, это самые строгие требования к IT, которые только есть в России.

В таком случае вариантов «как поудобнее» просто нет. Нам нужен был сертифицированный гипервизор, сертифицированная ОС в виртуалках и обязательно сертифицированное СЗИ от НСД (то есть, защита от несанкционированного доступа). Я выбрал Astra Linux Special Edition Брест 1.7. У «Бреста» есть собственный встроенный гипервизор, который является форком KVM с инструментами ALT, и, что самое главное, сертификаты ФСТЭК на уровень СВТ-3, а для медицины этого более чем достаточно.

Особенности Бреста vs обычного KVM

• Мандатный контроль целостности (МКЦ) и мандатное управление доступом (МРД) — на уровне ядра ОС, нельзя обойти.
• Встроенный антивирус Касперский на уровне гипервизора с интеграцией в систему аудита.
• Графический инструмент управления Брест-VM, по сути аналог virt-manager с более жёсткими политиками.
• Поддержка только сертифицированных гостевых ОС: Astra Linux, Альт, отдельные сертифицированные сборки Windows.
• Обновления через российский репозиторий repository.astralinux.ru, без обращения к зарубежным серверам.

Вживую такая инсталляция выглядит даже проще, чем zVirt. «Брест» поставляется как готовый ISO-образ, в который уже включена гипервизорная часть.

# Установка Брест 1.7 на сервер R740xd
# Все стандартные пакеты гипервизора входят в дистрибутив

# После установки добавление в кластер Бреста через web-интерфейс
# Главный инструмент — brest-cluster-manager на порту 8443

# Создание ВМ из CLI
sudo virsh define /etc/libvirt/qemu/med-app01.xml
sudo virsh start med-app01

# Включение МКЦ для ВМ — критично для соответствия К1
brest-mac-policy set --vm med-app01 --policy strict --integrity high

# Резервное копирование через сертифицированный модуль
brest-backup create --vm med-app01 --target /backup/med --schedule daily-02:00

Особенность кейса медклиники — мы не переносили ВМ через V2V из VMware. Это было сознательное решение: проще пересобрать виртуалки с нуля на сертифицированной Astra, чем тащить «грязное» наследие Windows-инсталляций. Из 9 виртуалок старого парка пять заменили на свежий Astra Server, четыре оставили как Windows (медсофт стоматологии работает только на Windows) и сертифицировали отдельно.

Что касается бюджета, то за нашу работу (28 рабочих дней, включая аттестацию) мы взяли 720 000 ₽, плюс лицензии «Брест» на год обошлись в 480 000 ₽. Да, это дороже, чем в других кейсах, но регуляторика всегда добавляет к любому проекту 30-40% стоимости.

Сводная таблица четырёх миграций

Чтобы было совсем наглядно, вот итоги по всем четырём проектам:

• Производство 47 РМ: zVirt 4.3 HCI, 21 рабочий день, 540 000 ₽ работы + 1.2 млн лицензий за 3 года, экономия 3.6 млн.
• Юрфирма 38 РМ: Proxmox VE 8.4 + Ceph, 16 рабочих дней, 380 000 ₽ работы + 220 000 подписки enterprise repo на 5 лет.
• Торговля 28 РМ: Hyper-V 2022 Datacenter, 12 рабочих дней, 290 000 ₽ работы + 0 (лицензии Datacenter уже были).
• Медклиника 22 РМ: Astra Linux Брест 1.7, 28 рабочих дней с аттестацией, 720 000 ₽ работы + 480 000 лицензий + 280 000 за услуги аттестующей организации.

В среднем, полная миграция у нас занимала 19 рабочих дней. Средний бюджет на работы выходил в 482 тысячи рублей. А средний срок окупаемости составлял всего 7 месяцев, если сравнивать со сценарием «продлить VMware на тот же период».

Какие грабли проходят все четыре проекта

Интересно, что, несмотря на совершенно разные стеки, в каждом проекте я постоянно сталкивался с одними и теми же проблемными точками:

• VMware Tools. После миграции в любую другую платформу нужно удалить VMware Tools и поставить аналог (qemu-guest-agent, Hyper-V Integration Services, Брест-агент). Иначе ВМ работает, но обмен между гостем и гипервизором сломан.
• Жёстко прописанные IP-адреса. В каждом из четырёх проектов нашлись 5-15 интеграций, где адрес сервера был прописан не как FQDN, а как IP. При миграции с сохранением адресации это не проблема, при смене сетевой схемы — катастрофа.
• Снэпшоты-долгожители. На vSphere у каждого второго клиента есть снэпшоты возрастом 1-3 года, занимающие десятки гигабайт. Перед миграцией все снэпшоты обязательно консолидируем — иначе V2V переносит и продакшен, и снэпшот как отдельные диски.
• Лицензии 1С на USB-токенах. В четырёх проектах из четырёх. На VMware прокидка через usb passthrough работала, на новых стеках — у каждого свой механизм. На zVirt пришлось ставить usb/ip-server, на Proxmox — qemu-passthrough с pinning, на Hyper-V — DDA (Discrete Device Assignment) только на топовом железе, на Брест — пересдавать лицензию через личный кабинет 1С.
• VMware Distributed Switch. Если у клиента был vDS с какой-нибудь специфичной фичей (Network I/O Control, LACP), переезд требует пересборки сетевой части. На Proxmox — через OpenVSwitch, на Hyper-V — через SET (Switch Embedded Teaming).

Что я не сделаю в 2026 году ни за какие деньги

После нашего опыта четырёх миграций я перестал предлагать клиентам несколько вещей. Вот они:

• Не буду продлевать VMware vSphere Standard через серые схемы. Слишком высок риск, что лицензия отвалится через год, а патчи не придут.
• Не буду собирать гетерогенный парк (часть — Hyper-V, часть — Proxmox) у одного клиента «для разнообразия». Поддержка двух стеков обходится дороже сэкономленных 200 тысяч на лицензиях.
• Не буду брать в работу проект, где клиент отказывается заводить тестовую среду. Без тестовой ВМ перед миграцией — это лотерея с продакшеном на кону.
• Не буду делать миграцию «через выходные» без двух недель подготовки. У меня в 2024-м был один такой проект (соглашался под давлением сроков), и в понедельник всё легло на четыре часа из-за сетевой ошибки на edge-роутере. Урок выучил.
• Не буду рекомендовать OpenStack клиенту меньше 100 РМ. Это серьёзная экосистема под облачные нагрузки и крупных операторов; для офиса 30 человек это пушка по воробьям.

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

Сколько клиентов вы уже перевели с VMware?

За 8 месяцев, с сентября 2025 по апрель 2026 года, мы в ITfresh успешно завершили четыре полноценные миграции с VMware. Производственная компания с 47 рабочими местами перешла на zVirt 4.3 HCI, юридическая фирма с 38 рабочими местами — на Proxmox VE 8.4, торговая компания с 28 рабочими местами — на Hyper-V Server 2022, а медклиника с 22 рабочими местами — на Astra Linux + KVM. И это ещё не всё, у нас сейчас в работе ещё две миграции!

Какой гипервизор вы советуете по умолчанию?

У нас нет какого-то универсального решения по умолчанию, и это моё сознательное решение. Для нагрузок 1С + AD + файловый сервер до 30 рабочих мест отлично подходит Proxmox 8.4, он самый доступный и хорошо поддерживается. Для производства, где есть требования ФСТЭК, мы выбираем zVirt 4.3. Если офис полностью завязан на экосистеме Microsoft (Office 365, AD, RDS), то тут однозначно Hyper-V 2022. А для критичной инфраструктуры с госзаказчиком — только Astra Linux Брест или KVM. Запомните: стек всегда выбирается под клиента, а не наоборот.

Можно ли просто докупить лицензии VMware и не дёргаться?

Можно, конечно, остаться на VMware, но я категорически этого не советую. С 2024 года российские реселлеры просто физически не могут отгружать новые VMware-лицензии, разве что через какие-то «серые» схемы. Патчи приходят с задержкой в 4-6 месяцев. А стоимость подписки от Broadcom выросла на фантастические 1500% по сравнению с perpetual-лицензиями 2022 года. Через пару лет продлить будет либо вообще нечем, либо это обойдётся в безумные деньги. Мой совет: лучше уйти спокойно, пока у вас ещё есть время на продуманное проектирование.

Сколько стоит проект миграции под ключ?

У нас в ITfresh цена зависит от количества виртуальных машин и, конечно, от сложности сетевой архитектуры. Например, для офиса на 30 рабочих мест с 12-15 виртуалками работы обойдутся от 380 000 ₽, плюс стоимость лицензий нового гипервизора. Для производственной компании на 50 рабочих мест с HCI и микросегментацией это будет уже 540-700 000 ₽. В эту сумму, кстати, входит полный пакет: аудит, проектирование, сама миграция и даже обучение штатного администратора клиента.

Что делать с Veeam Backup и репликацией?

Veeam Backup & Replication 12.1 поддерживает Hyper-V и VMware из коробки, Proxmox через open-source плагин (image-level бэкап работает с ограничениями), zVirt — только агентный бэкап через Veeam Agent внутри ВМ. Для большинства наших клиентов мы оставляем агентную схему: она проще, надёжнее и не зависит от вендорных API гипервизора.

Итог

VMware просуществовала 25 лет и, безусловно, по праву стала классикой. Однако в 2026 году для российского бизнеса просто нет никакого экономического и политического смысла на ней оставаться. Стратегия миграции у каждой компании, как вы видите, своя: производство — на zVirt, юрфирма — на Proxmox, торговля — на Hyper-V, медицина — на Брест. Главное, что я хочу подчеркнуть, — всегда выбирайте стек под ваш бизнес, а не под мимолётную моду. Мы в ITfresh готовы пройти этот путь вместе с вами: от детальной проектировки до полноценной поддержки. Контракт на 6-12 месяцев гарантирует, что после переезда у вас всё будет работать как часы.