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

Мы провели полный аудит текущей VMware-инфраструктуры:

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

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

Суммарно: 328 ГБ RAM и 5.7 ТБ дисков. Утилизация хостов — около 65%, что оставляло запас для роста.

Мы рассматривали несколько альтернатив:

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

План миграции мы разделили на 5 фаз:

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

Установка 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% дискового пространства.

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

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

# На первом хосте — создание кластера
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

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

Для VLAN-aware bridge мы настроили теги VLAN, соответствующие сетевой сегментации ЩитПолис:

• 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 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 (QEMU Copy On Write) мы выбрали по нескольким причинам: поддержка thin provisioning (диск занимает только реально использованное место), встроенные снапшоты и совместимость с Proxmox Backup Server. Альтернатива — RAW-формат на ZFS — даёт лучший I/O на 5–10%, но мы решили начать с qcow2 для простоты миграции, а при необходимости конвертировать в RAW позже.

После конвертации мы импортировали каждую 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-драйверами, так как модули virtio включены в ядро Linux начиная с версии 2.6. Для Windows потребовалась установка VirtIO-драйверов после первого запуска. Мы подготовили ISO-образ с драйверами, подписанными Microsoft WHQL (Windows Hardware Quality Labs), что гарантировало совместимость и стабильность:

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

В 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 для максимальной производительности на 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)

Каждая 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 оказался на диске с другой буквой. Решение: пересоздание tempdb через ALTER DATABASE

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

Мы провели бенчмарки на идентичных VM до и после миграции:

Proxmox показал лучшую производительность практически во всех тестах. Особенно заметно — дисковый I/O (+17%), что объясняется переходом на ZFS с L2ARC и SLOG вместо аппаратного RAID.

# План 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 минут

Cutover прошёл без инцидентов. Все 25 VM были запущены на Proxmox к 9:00, тестирование заняло 2 часа, и к 11:00 система была полностью в продакшне.

Проект миграции занял 9 рабочих дней:

Ключевые результаты:

• Экономия 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, бэкапы и восстановление. Proxmox имеет интуитивный веб-интерфейс, и администратор, привыкший к vSphere, освоил ключевые операции за первый день.