VMware прошла путь от Workstation 1.0 в 1999-м до фактического конца эпохи в 2026-м для российских клиентов

Виртуализация 3 мая 2026 · 19 мин чтения · Семёнов Е.С., руководитель ITfresh

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

У меня дома до сих пор лежит коробка с VMware Workstation 4.5 — я её купил в 2004-м за 199 долларов и поднимал на ней свои первые тестовые лабы. За 25 лет VMware изменила индустрию: создала vMotion, DRS, vSAN, NSX — каждый из этих терминов стал стандартным мышлением системного администратора. К нам в ITfresh в 2025-2026 году пришли четыре клиента с одним и тем же вопросом: «Что делать дальше с 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 рабочий день, экономия за три года против VMware — 3.6 млн ₽, 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-репликации, по 4 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, аттестация информационных систем персональных данных. Это самый строгий из российских требований к ИТ.

Тут нет вариантов «как удобнее»: нужен сертифицированный гипервизор, сертифицированная ОС в виртуалках, сертифицированное СЗИ от НСД (защита от несанкционированного доступа). Я выбрал 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) и сертифицировали отдельно.

Бюджет — 720 000 ₽ за работу (28 рабочих дней с учётом аттестации), плюс лицензии Брест на год 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 и не дёргаться?

Можно, но я этого не советую. С 2024 года российские реселлеры физически не могут отгружать новые VMware-лицензии без серых схем, патчи приходят с задержкой 4-6 месяцев. Cтоимость подписки от 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 месяцев гарантирует, что после переезда у вас всё работает.

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

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

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

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