Лицензия VMware выросла в 4 раза: переносим 25 виртуальных машин на Proxmox

Задача клиента: страховая компания не может платить за VMware после Broadcom

В декабре 2025 года к нам обратилась страховая компания ЩитПолис из Уфы. 12 лет на рынке, более 50 000 полисов, 80 человек в трёх офисах — серьёзный бизнес. Вся инфраструктура жила на VMware vSphere 7: два хоста ESXi, 25 виртуальных машин.

Когда Broadcom поглотил VMware в ноябре 2023 года, лицензионная политика изменилась радикально. Perpetual-лицензии исчезли. Всё — только подписка, а минимальный порог входа вырос до уровня, на который рассчитывают крупные корпорации, а не региональный страховщик.

«Мы платили около 420 000 ₽ в год за vSphere Standard с поддержкой. После перехода Broadcom нам выставили 1 700 000 ₽. Это увеличение в 4 раза за тот же функционал. Для компании нашего размера это неподъёмно» — IT-директор ЩитПолис.

Платить новую цену компания не могла. Но и просто «остаться на старом» — тоже не вариант: серверы были частью PCI DSS-совместимой инфраструктуры, обрабатывающей страховые платежи. Без обновлений и поддержки — прямой путь к проблемам с аудитом.

Аудит виртуальной инфраструктуры

Начали с аудита того, что есть. Полного — без скидок на «это и так понятно».

Физические хосты:

ХостМодельCPURAMХранилище
esxi-01Dell R6402× Xeon Gold 5218 (32 ядра)256 ГБ8× 1.2 ТБ SAS (RAID-10) = 4.8 ТБ
esxi-02Dell R6402× Xeon Gold 5218 (32 ядра)256 ГБ8× 1.2 ТБ SAS (RAID-10) = 4.8 ТБ

Виртуальные машины (25 штук):

КатегорияКол-во VMОССуммарно RAMСуммарно диск
Бизнес-приложения (1С, CRM)5Windows Server 2019/202280 ГБ1.2 ТБ
Базы данных (MSSQL, PostgreSQL)3Windows/Linux64 ГБ2.0 ТБ
Веб-сервисы (портал, API)6Ubuntu 22.0448 ГБ600 ГБ
Инфраструктура (AD, DNS, DHCP)4Windows Server 202232 ГБ400 ГБ
Мониторинг и логи3Ubuntu 22.0424 ГБ800 ГБ
Терминальные серверы2Windows Server 202264 ГБ500 ГБ
Тестовые среды2Разные16 ГБ200 ГБ

Итого: 328 ГБ RAM и 5.7 ТБ дисков. Хосты загружены примерно на 65% — есть куда расти, никакого аврала с ресурсами.

Выбор Proxmox VE и план миграции

Альтернативы мы смотрели честно, без предвзятости.

РешениеЛицензияKVM/LXCHA-кластерВеб-интерфейсПоддержка
Proxmox VEAGPL (бесплатно)KVM + LXCДаПолноценныйПлатная подписка
oVirt / RHEVApache 2.0KVMДаЕстьСообщество
XCP-ngGPLv2XenДаЧерез XOПлатная

Proxmox выиграл. Зрелый веб-интерфейс, кластеризация без лишних движений, ZFS из коробки, живое сообщество — и коммерческая поддержка, если понадобится, по вменяемым деньгам.

Миграцию разбили на 5 фаз — никаких «переедем за выходные одним куском».

  • Фаза 1 — Установка Proxmox и настройка кластера (1 день)
  • Фаза 2 — Экспорт VM из VMware и конвертация дисков (2 дня)
  • Фаза 3 — Импорт и настройка VM в Proxmox (2 дня)
  • Фаза 4 — Тестирование (3 дня, параллельная работа)
  • Фаза 5 — Cutover и деком VMware (1 день, выходной)

Установка Proxmox VE и настройка кластера

Поставили Proxmox VE 8.2 на оба хоста. Принципиальный момент: ставили на новые диски, а не поверх существующего. В каждый сервер добавили по 2× NVMe SSD 480 ГБ — под Proxmox и ZFS metadata. SAS-диски, которые уже были, отдали под хранилище VM.

Установка Proxmox и создание ZFS-пула

Установка Proxmox VE с ISO на каждый хост:

# После установки — обновление до актуальной версии
apt update && apt full-upgrade -y

# Удаление enterprise-репозитория (если нет подписки)
rm /etc/apt/sources.list.d/pve-enterprise.list

# Добавление no-subscription репозитория
echo 'deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription' > /etc/apt/sources.list.d/pve-no-subscription.list
apt update

Создание ZFS-пула из SAS-дисков для хранения виртуальных машин:

# На каждом хосте: 8× 1.2 ТБ SAS в RAID-10 (mirror + stripe)
# Сначала удаляем RAID-конфигурацию контроллера (переводим в JBOD)
# Далее создаём ZFS mirror vdevs:

zpool create -f vmpool \
  mirror /dev/sda /dev/sdb \
  mirror /dev/sdc /dev/sdd \
  mirror /dev/sde /dev/sdf \
  mirror /dev/sdg /dev/sdh

# Настройка ZFS для виртуализации
zfs set compression=lz4 vmpool
zfs set atime=off vmpool
zfs set recordsize=64K vmpool  # Оптимально для VM-дисков

# Добавление ZFS SLOG (write cache) на NVMe
zpool add vmpool log mirror /dev/nvme0n1p3 /dev/nvme1n1p3

# Добавление ZFS L2ARC (read cache) на NVMe
zpool add vmpool cache /dev/nvme0n1p4

# Проверка
zpool status vmpool
# NAME                    STATE     READ WRITE CKSUM
# vmpool                  ONLINE       0     0     0
#   mirror-0              ONLINE       0     0     0
#     sda                 ONLINE       0     0     0
#     sdb                 ONLINE       0     0     0
#   mirror-1              ONLINE       0     0     0
#   ...
#   log
#     mirror-4            ONLINE       0     0     0
#   cache
#     nvme0n1p4           ONLINE       0     0     0

ZFS дал нам два реальных плюса перед аппаратным RAID. Первый — встроенные снапшоты: перед миграцией каждой VM мы делали моментальный «откат» бесплатно. Второй — сжатие lz4, которое на практике съедало 20–30% дискового пространства.

Здесь есть один момент, который люди часто упускают. Чтобы ZFS нормально работал, контроллер нужно перевести из RAID-режима в JBOD (Just a Bunch Of Disks) — иначе ZFS не видит диски напрямую. На контроллерах Dell PERC это делается через BIOS контроллера (Ctrl+R при загрузке) или через утилиту perccli. Аппаратный RAID «между» ZFS и дисками не просто бесполезен — он вреден: скрывает реальное состояние дисков и ломает механизм самовосстановления.

Создание Proxmox-кластера и настройка сети

Объединили два хоста в кластер:

# На первом хосте — создание кластера
pvecm create shitpolis-cluster

# На втором хосте — присоединение
pvecm add 10.0.1.1  # IP первого хоста
# Password: (вводим root-пароль первого хоста)

# Проверка кластера
pvecm status
# Cluster information
# ~~~~~~~~~~~~~~~~~~~
# Name:             shitpolis-cluster
# Config Version:   2
# Transport:        knet
# Secure:           on
# Quorum information
# ~~~~~~~~~~~~~~~~~~
# Date:             ...
# Quorum provider:  corosync_votequorum
# Nodes:            2
# Node ID: 1  pve1  Online
# Node ID: 2  pve2  Online

Сетевая конфигурация на каждом хосте:

# /etc/network/interfaces (pve1)
auto lo
iface lo inet loopback

# Management network
auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.0.1.1/24
    gateway 10.0.1.254
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

# VM traffic (VLAN-aware bridge)
auto eno2
iface eno2 inet manual

auto vmbr1
iface vmbr1 inet manual
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

# Corosync / migration (dedicated 10G link)
auto eno3
iface eno3 inet static
    address 10.10.1.1/24

Для corosync и live migration выделили отдельный интерфейс 10 Гбит/с. Без этого миграция VM между хостами растягивается на минуты — с ним укладывается в секунды. Разница принципиальная.

VLAN-aware bridge настроили под сетевую сегментацию ЩитПолис — теги соответствуют тому, что было в VMware:

  • VLAN 10 — серверы приложений (1С, CRM)
  • VLAN 20 — базы данных (изолированный сегмент)
  • VLAN 30 — веб-сервисы (DMZ)
  • VLAN 40 — инфраструктура (AD, DNS, DHCP)
  • VLAN 50 — мониторинг
  • VLAN 100 — management

При импорте каждая VM получала нужный VLAN-тег через параметр tag=XX в конфигурации сетевого интерфейса. Никакой ручной правки после — всё сразу в нужном сегменте.

Экспорт VM из VMware и конвертация дисков

Самый нервный этап — вытащить машины из VMware и перегнать в формат, который поймёт Proxmox. Подходов было два, выбирали в зависимости от типа VM.

Экспорт через ovftool и конвертация VMDK в qcow2

Большинство VM экспортировали через VMware ovftool, конвертировали через qemu-img:

# Установка ovftool (скачивается с VMware)
sudo sh VMware-ovftool-4.6.0-*.bundle

# Экспорт VM из vCenter/ESXi в формат OVA
ovftool --noSSLVerify \
  'vi://admin@vsphere.local@vcenter.shitpolis.local/Datacenter/vm/billing-server' \
  /export/billing-server.ova

# Распаковка OVA (это tar-архив)
tar xf /export/billing-server.ova -C /export/billing-server/

# Конвертация VMDK → qcow2
qemu-img convert -f vmdk -O qcow2 -p \
  /export/billing-server/billing-server-disk1.vmdk \
  /export/billing-server/billing-server-disk1.qcow2

# Проверка образа
qemu-img info /export/billing-server/billing-server-disk1.qcow2
# image: billing-server-disk1.qcow2
# file format: qcow2
# virtual size: 200 GiB
# disk size: 87.3 GiB  (сжатие qcow2!)

Под пакетную конвертацию всех 25 VM написали скрипт — руками это делать нет никакого смысла:

#!/bin/bash
# /opt/scripts/batch-convert.sh

EXPORT_DIR="/export"
OUTPUT_DIR="/converted"

for ova in ${EXPORT_DIR}/*.ova; do
    VM_NAME=$(basename "$ova" .ova)
    echo "[$(date)] Обработка: ${VM_NAME}"

    mkdir -p "${OUTPUT_DIR}/${VM_NAME}"

    # Распаковка
    tar xf "$ova" -C "${OUTPUT_DIR}/${VM_NAME}/"

    # Конвертация всех VMDK
    for vmdk in ${OUTPUT_DIR}/${VM_NAME}/*.vmdk; do
        QCOW2="${vmdk%.vmdk}.qcow2"
        echo "  Конвертация: $(basename $vmdk)"
        qemu-img convert -f vmdk -O qcow2 -p "$vmdk" "$QCOW2"
        rm "$vmdk"  # Удаляем VMDK после конвертации
    done

    echo "[$(date)] Готово: ${VM_NAME}"
done

Все 25 VM сконвертировались примерно за 6 часов. Узкое место — скорость чтения SAS-дисков, не сеть и не процессор.

Формат qcow2 выбрали осознанно. Thin provisioning — диск занимает ровно столько, сколько реально записано. Встроенные снапшоты. Совместимость с Proxmox Backup Server. Да, RAW на ZFS даёт плюс 5–10% к I/O — но для первой миграции qcow2 проще и надёжнее, а перегнать в RAW можно позже, когда всё устаканится.

Импорт VM в Proxmox

После конвертации — импорт каждой VM в Proxmox. Процесс для каждой машины:

# Создание VM в Proxmox (пример для биллинг-сервера)
# VMID 101, 8 ядер, 32 ГБ RAM, UEFI boot
qm create 101 \
  --name billing-server \
  --memory 32768 \
  --cores 8 \
  --sockets 1 \
  --cpu host \
  --net0 virtio,bridge=vmbr1,tag=10 \
  --ostype win10 \
  --bios ovmf \
  --efidisk0 vmpool:1,efitype=4m,pre-enrolled-keys=1 \
  --scsihw virtio-scsi-single \
  --machine q35

# Импорт qcow2-диска в ZFS-пул
qm importdisk 101 /converted/billing-server/billing-server-disk1.qcow2 vmpool

# Подключение диска к VM
qm set 101 --scsi0 vmpool:vm-101-disk-1,discard=on,iothread=1,ssd=1

# Установка загрузочного диска
qm set 101 --boot order=scsi0

# Добавление VirtIO драйверов ISO (для Windows)
qm set 101 --ide2 local:iso/virtio-win-0.1.240.iso,media=cdrom

С Linux-машинами всё прошло гладко — они поднялись сразу, потому что модули virtio встроены в ядро начиная с версии 2.6. А вот Windows потребовала отдельного внимания: после первого запуска пришлось устанавливать VirtIO-драйверы. Мы заранее подготовили ISO с драйверами, сертифицированными по программе Microsoft WHQL (Windows Hardware Quality Labs), — это принципиальный момент для стабильности в продакшне:

  • VirtIO SCSI (диски)
  • VirtIO Network (сеть)
  • VirtIO Balloon (управление памятью)
  • QEMU Guest Agent

Настройка сети и особенности Windows VM

Перенос VM — это не просто конвертация дисков. Звучит банально, но именно здесь большинство проектов и спотыкаются. Сетевая конфигурация, драйверы, особенности конкретной ОС — каждый из этих пунктов способен превратить «быструю миграцию» в многочасовой разбор полётов.

Реконфигурация сети в VM

В VMware использовался драйвер VMXNET3, в Proxmox — VirtIO. Смена стека означала одно: сетевые интерфейсы в гостевых ОС получали новые MAC-адреса и новые имена. Казалось бы, мелочь — но именно из-за этого у нас однажды на другом проекте упал мониторинг на трёх машинах сразу.

Для Linux-машин:

# На каждой Linux VM после миграции
# 1. Удаляем привязку к старому интерфейсу
sudo rm /etc/udev/rules.d/70-persistent-net.rules 2>/dev/null

# 2. Обновляем Netplan (Ubuntu)
# Заменяем ens160/ens192 (VMware) на ens18 (Proxmox VirtIO)
sudo cat > /etc/netplan/01-netcfg.yaml << 'EOF'
network:
  version: 2
  ethernets:
    ens18:
      addresses:
        - 10.0.10.15/24
      routes:
        - to: default
          via: 10.0.10.1
      nameservers:
        addresses:
          - 10.0.1.10
          - 10.0.1.11
EOF

sudo netplan apply

С Windows было чуть сложнее — установка VirtIO-драйверов плюс ручная перенастройка IP:

# PowerShell: установка VirtIO-драйверов с ISO
$certStore = Get-Item "cert:\LocalMachine\TrustedPublisher"
$certStore.Open("ReadWrite")
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("E:\cert\viostor.cat")
pnputil /add-driver E:\vioscsi\w10\amd64\*.inf /install
pnputil /add-driver E:\NetKVM\w10\amd64\*.inf /install
pnputil /add-driver E:\Balloon\w10\amd64\*.inf /install
pnputil /add-driver E:\vioserial\w10\amd64\*.inf /install

# Установка QEMU Guest Agent
msiexec /i E:\guest-agent\qemu-ga-x86_64.msi /quiet

Оптимизация производительности VM

После того как все VM оказались на новой платформе, мы прошлись по каждой и подкрутили параметры под KVM. Без этого шага производительность могла бы остаться на уровне «и так работает» — а нам нужен был максимум.

# Оптимальные параметры для критичных VM (пример: MSSQL-сервер)
qm set 105 \
  --cpu host \
  --numa 1 \
  --balloon 0 \
  --cores 12 \
  --memory 65536 \
  --scsi0 vmpool:vm-105-disk-0,discard=on,iothread=1,ssd=1,cache=writeback \
  --agent enabled=1

# hugepages для VM с БД
qm set 105 --hugepages 1024

Что именно меняли:

  • cpu host — проброс реальных CPU-инструкций (критично для MSSQL и 1С, где каждая миллисекунда на счету)
  • balloon 0 — для баз данных ballooning отключаем всегда: память должна быть предсказуемой, а не «изъятой» гипервизором в самый неподходящий момент
  • iothread=1 — каждый диск получает выделенный поток для I/O, не делит его с соседями
  • discard=on — проброс TRIM-команд на SSD, иначе диск деградирует быстрее
  • cache=writeback — ускоряет запись, но только если есть UPS и ZFS ZIL; без них лучше не трогать

Тестирование и параллельная работа

Перед финальным переключением мы три дня гоняли обе инфраструктуры параллельно. VMware оставался основным, Proxmox крутил копии VM — мы смотрели, как они себя ведут под реальной нагрузкой. Три дня — это не перестраховка, это минимум, который позволяет поймать неочевидные проблемы.

Функциональное тестирование

Каждая VM прошла чек-лист:

# Чек-лист тестирования VM после миграции

□ VM загружается без ошибок
□ Сеть доступна, IP корректный
□ DNS-резолвинг работает
□ Приложение запускается и отвечает
□ БД доступна, данные целы
□ Бэкап создаётся и восстанавливается
□ Мониторинг (Zabbix agent) подключен
□ QEMU Guest Agent отвечает
□ Производительность не хуже VMware (±5%)

Проблемы, которые мы поймали на этапе тестирования:

  • Windows Server 2019 (1С) — BSOD при загрузке: VMware Tools и VirtIO конфликтовали на уровне драйверов. Лечится через Safe Mode: удаляем VMware Tools, ставим VirtIO — и машина встаёт нормально.
  • Ubuntu (веб-сервер) — cloud-init при каждой загрузке лез переконфигурировать сеть. Одна команда решила проблему: sudo touch /etc/cloud/cloud-init.disabled
  • MSSQL — после миграции tempdb обнаружился на диске с другой буквой. Пришлось пересоздавать через ALTER DATABASE. Неприятно, но решаемо за 20 минут.

Каждую проблему мы фиксировали сразу — с описанием симптома и конкретным решением. Этот документ теперь живёт в IT-отделе ЩитПолис и уже пригодился при добавлении новых VM. Если планируете миграцию — начинайте с тестовых и некритичных машин. Всегда. На продакшне учиться дорого.

Сравнение производительности

Прежде чем делать выводы, мы прогнали бенчмарки — на идентичных VM до миграции и после:

ТестVMware vSphere 7Proxmox VE 8.2Разница
fio random read IOPS (4K)45 20052 800+16.8%
fio random write IOPS (4K)38 10044 600+17.1%
fio sequential read MB/s1 2501 380+10.4%
sysbench CPU (events/s)12 40012 650+2.0%
sysbench memory MB/s8 2008 350+1.8%
iperf3 network Gbps9.29.4+2.2%
1С: проведение 1000 документов47 сек43 сек-8.5%

Proxmox оказался быстрее почти по всем показателям. Дисковый I/O вырос на 17% — и это не магия, а вполне конкретная причина: ZFS с L2ARC и SLOG против аппаратного RAID с его ограничениями.

Cutover и результаты миграции

Финальное переключение поставили на субботу — чтобы даже в случае форс-мажора бизнес не почувствовал. План cutover выглядел так:

Процедура cutover

# План cutover (суббота, 8:00 - 14:00)

08:00 — Уведомление пользователей, закрытие доступа
08:15 — Финальная синхронизация данных VMware → Proxmox
         (rsync изменений за последние 3 дня)
08:30 — Остановка VM на VMware
09:00 — Запуск VM на Proxmox
09:15 — Проверка сети, DNS, доступность сервисов
09:30 — Функциональное тестирование (IT-отдел)
10:00 — Тестирование бизнес-пользователями (5 ключевых)
11:00 — Переключение DNS-записей на новые IP (если менялись)
12:00 — Открытие доступа для всех пользователей
13:00 — Мониторинг, сбор обратной связи
14:00 — Cutover завершён

# Rollback plan (если что-то пошло не так):
# → Остановить VM на Proxmox
# → Запустить VM на VMware
# → Откатить DNS
# → Время отката: 15 минут

Всё прошло чисто. К 9:00 все 25 VM работали на Proxmox, два часа ушло на тестирование, и в 11:00 система вышла в полноценный продакшн. Без инцидентов.

Финальные результаты

Весь проект занял 9 рабочих дней:

МетрикаVMware vSphereProxmox VE 8.2
Лицензия (год)1 700 000 ₽0 ₽ (Community) / 150 000 ₽ (подписка)
Количество VM2525
Дисковый I/O (IOPS)45 20052 800 (+17%)
Время snapshot2-5 сек< 1 сек (ZFS)
Веб-интерфейсvSphere Client (Flash/HTML5)Proxmox Web GUI
Live MigrationДа (vMotion)Да (QEMU live migration)
БэкапVeeam (доп. лицензия)Proxmox Backup Server (встроенный)

Что получили в итоге:

  • Экономия 1 550 000 ₽/год на лицензиях — и это уже с учётом подписки Proxmox
  • +17% к производительности дискового I/O — спасибо ZFS
  • 0 потерянных данных при переносе 25 VM
  • 4 часа простоя — суббота, плановое окно, всё под контролем
  • 25 из 25 VM мигрированы успешно
«Мы сэкономили полтора миллиона в год и получили более быструю систему. Proxmox оказался проще в администрировании, чем vSphere — наш админ освоился за неделю» — IT-директор ЩитПолис.

Параллельно с миграцией настроили Proxmox Backup Server. Он закрыл задачу бэкапов и заменил Veeam — ещё одна лицензия, от которой удалось избавиться. PBS делает инкрементальные бэкапы с дедупликацией, и объём хранилища под резервные копии сократился на 60% по сравнению с полными копиями. Для нас это была приятная неожиданность.

Напоследок провели двухчасовой воркшоп с системным администратором ЩитПолис: создание VM, снапшоты, live migration, бэкапы и восстановление. Человек до этого работал с vSphere — и уже к концу первого дня уверенно ориентировался в веб-интерфейсе Proxmox. Интерфейс там действительно понятный, без лишних слоёв абстракции.

Часто задаваемые вопросы

Полностью без остановки — не получится. VM нужно остановить на VMware и поднять на Proxmox, это факт. Но простой можно сжать до 15–30 минут: заранее копируете и конвертируете диски, настраиваете VM на новой стороне, а в момент cutover только досинхронизируете изменения за последние несколько часов и переключаете. Мы именно так и делаем на проектах, где каждая минута простоя — деньги.

Технически Proxmox VE прекрасно работает и без подписки — никаких искусственных ограничений нет. Но для продакшна мы всё-таки берём подписку (от 110 евро/год за сокет): только так получаешь доступ к enterprise-репозиторию с проверенными, «устоявшимися» обновлениями и живую техподдержку. Страховой компании, где простой измеряется штрафами и репутацией, нестабильное обновление — последнее, что нужно.

Windows-машины на Proxmox работают без сюрпризов — главное поставить VirtIO-драйверы. Они бесплатные и подписаны Microsoft WHQL, так что никаких конфликтов с политиками безопасности. Поддерживаются Windows Server 2016/2019/2022/2025 и десктопные версии. По производительности VirtIO как минимум не уступает VMware PVSCSI/VMXNET3, а в дисковых операциях нередко и обгоняет.

Да, и на ZFS это даже правильнее. ZFS сам занимается снапшотами и сжатием, так что qcow2 в этой связке просто дублирует функции — смысла нет. RAW-диск на ZFS даёт на 5–10% лучший I/O, чем qcow2, и это реальные цифры из нашей практики, а не маркетинг. Конвертация одной командой: qemu-img convert -f vmdk -O raw disk.vmdk disk.raw.

VMware Tools нужно убрать — либо до миграции, либо сразу после. В Linux это vmware-uninstall-tools.pl или apt remove open-vm-tools, в Windows — обычное удаление через «Программы и компоненты». Оставлять их «на потом» не стоит: конфликты с гостевой системой вылезают в самый неподходящий момент. Вместо VMware Tools ставим QEMU Guest Agent — он отвечает за корректное завершение работы, freeze/thaw файловой системы во время бэкапов и отображение IP-адресов прямо в веб-интерфейсе Proxmox.

Нужна помощь с настройкой?

Специалисты АйТи Фреш помогут с внедрением и настройкой — 15+ лет опыта, обслуживание от 15 000 ₽/мес

📞 Связаться с нами
#миграция VMware Proxmox#Broadcom VMware лицензия#конвертация VMDK qcow2#Proxmox VE установка#замена VMware vSphere#экспорт OVA VMware#ZFS Proxmox#виртуализация Linux