Миграция с VMware на KVM: 50 серверов ТрансЛог за 8 недель

Логистическая компания «ТрансЛог» — 1200 сотрудников, 18 филиалов по России, собственный центр обработки данных с 50 серверами на платформе VMware vSphere 7. В январе 2026 года руководство приняло решение о миграции на отечественные и открытые решения после того, как:

• Стоимость лицензий VMware выросла на 300% после поглощения Broadcom. Годовой бюджет на лицензирование составлял 12 миллионов рублей — и это без Enterprise Plus, только Standard.
• Прекращение поддержки — VMware перестала продавать лицензии и обновления российским компаниям. Критические уязвимости закрывались с задержкой в 3-6 месяцев через неофициальные каналы.
• Зависимость от вендора — миграция на любую альтернативу усложнялась с каждым годом из-за проприетарных форматов и интеграций.

Компания обратилась к нам в itfresh.ru с чётким ТЗ: перенести все 50 виртуальных машин на KVM без даунтайма критических сервисов. Бюджет — ноль на лицензии (KVM — часть ядра Linux), инвестиции только в работу и оборудование.

Инфраструктура клиента на момент обращения:

• 8 физических серверов Dell PowerEdge R740 (2× Xeon Gold 6230, 256 GB RAM, 4× NVMe 1.92TB)
• 50 виртуальных машин: 30 Linux (Ubuntu, CentOS), 20 Windows Server (2016, 2019)
• VMware vCenter для управления
• VMware VSAN для общего хранилища
• Критические системы: 1С ERP, TMS (система управления транспортом), WMS (склад), Exchange, Active Directory

Прежде чем планировать миграцию, мы провели для IT-отдела «ТрансЛог» обучающую сессию по архитектуре KVM. Понимание внутреннего устройства критично для эксплуатации.

KVM (Kernel-based Virtual Machine) — это модуль ядра Linux, превращающий ядро в гипервизор типа 1. Он использует аппаратные расширения виртуализации процессора: Intel VT-x (инструкции VMX) и AMD SVM.

Архитектура KVM основана на двух режимах процессора:

• VMX root mode — режим гипервизора, в котором работает хостовая ОС и KVM
• VMX non-root mode — режим гостевой ВМ, в котором выполняется код виртуальных машин

Когда гостевая ВМ пытается выполнить привилегированную операцию (обращение к I/O, прерывание), процессор автоматически переключается в root mode — это называется VM-Exit. KVM обрабатывает событие и возвращает управление гостю через VM-Entry.

Модули ядра, которые мы загрузили на всех хостах:

# Проверка поддержки виртуализации
egrep -c '(vmx|svm)' /proc/cpuinfo
# Если > 0 — виртуализация поддерживается

# Загрузка модулей
modprobe kvm
modprobe kvm_intel   # Для Intel
# modprobe kvm_amd   # Для AMD

# Проверка загрузки
lsmod | grep kvm
# kvm_intel    380928  12
# kvm          1028096  1 kvm_intel

# Устройство /dev/kvm — точка входа для управления ВМ
ls -la /dev/kvm
# crw-rw---- 1 root kvm 10, 232 Apr  1 10:00 /dev/kvm

Для управления виртуальными машинами KVM использует связку QEMU + libvirt. QEMU эмулирует аппаратное обеспечение (диски, сеть, видео), а KVM обеспечивает аппаратное ускорение вычислений. Libvirt — это API и набор утилит (virsh, virt-manager) для удобного управления.

Установка полного стека на каждом хосте:

# Ubuntu 22.04
sudo apt install -y \
  qemu-kvm \
  libvirt-daemon-system \
  libvirt-clients \
  virtinst \
  virt-manager \
  bridge-utils \
  cpu-checker \
  ovmf          # UEFI firmware для Windows ВМ

# Проверка готовности
sudo kvm-ok
# INFO: /dev/kvm exists
# KVM acceleration can be used

# Добавление пользователя в группу libvirt
sudo usermod -aG libvirt $USER
sudo usermod -aG kvm $USER

VMware VSAN объединяла локальные NVMe-диски 8 серверов в единое хранилище. Для KVM мы выбрали Ceph — распределённое хранилище с аналогичной функциональностью.

Архитектура Ceph-кластера:

• 3 монитора (ceph-mon) — на 3 из 8 серверов
• 8 OSD-нод (ceph-osd) — все 8 серверов, по 4 NVMe на каждый = 32 OSD
• Суммарная ёмкость: 32 × 1.92 TB = 61.4 TB raw, ~20 TB usable (тройная репликация)

# Установка Ceph через cephadm (Reef 18.x)
curl --silent --remote-name https://download.ceph.com/rpm-reef/el9/noarch/cephadm
chmod +x cephadm
sudo ./cephadm bootstrap --mon-ip 10.10.1.11 --cluster-network 10.10.2.0/24

# Добавление остальных хостов
sudo ceph orch host add kvm-host-02 10.10.1.12
sudo ceph orch host add kvm-host-03 10.10.1.13
# ... для всех 8 хостов

# Добавление OSD (автоматически все доступные диски)
sudo ceph orch apply osd --all-available-devices

# Создание пула для виртуальных машин
sudo ceph osd pool create vm-pool 128 128
sudo ceph osd pool set vm-pool size 3   # тройная репликация
sudo rbd pool init vm-pool

Интеграция Ceph с libvirt:

# Создание секрета для аутентификации libvirt → Ceph
CEPH_KEY=$(sudo ceph auth get-key client.libvirt)
UUID=$(uuidgen)

cat > secret.xml << EOF

  ${UUID}
  
    client.libvirt secret
  

EOF

virsh secret-define secret.xml
virsh secret-set-value ${UUID} --base64 $(echo -n "${CEPH_KEY}" | base64)

# Определение storage pool в libvirt
cat > ceph-pool.xml << EOF

  ceph-vm-pool
  
    
    
    
    vm-pool
    
      
    
  

EOF

virsh pool-define ceph-pool.xml
virsh pool-start ceph-vm-pool
virsh pool-autostart ceph-vm-pool

Производительность Ceph мы протестировали перед миграцией: 120K IOPS random read (4K), 45K IOPS random write — что было сопоставимо с VSAN на той же аппаратной базе.

В VMware использовались distributed virtual switches с VLAN-тегированием. Для KVM мы настроили Linux bridge с аналогичной функциональностью.

Конфигурация сети на каждом хосте через Netplan:

# /etc/netplan/01-kvm-network.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
    eno2:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eno1, eno2]
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
  vlans:
    bond0.10:
      id: 10
      link: bond0
    bond0.20:
      id: 20
      link: bond0
    bond0.30:
      id: 30
      link: bond0
  bridges:
    br-mgmt:
      interfaces: [bond0.10]
      addresses: [10.10.10.11/24]
      routes:
        - to: default
          via: 10.10.10.1
      nameservers:
        addresses: [10.10.10.5]
    br-production:
      interfaces: [bond0.20]
      parameters:
        stp: false
        forward-delay: 0
    br-dmz:
      interfaces: [bond0.30]
      parameters:
        stp: false
        forward-delay: 0

Три bridge-интерфейса соответствовали трём сетевым зонам VMware:

• br-mgmt (VLAN 10) — управление: vCenter (теперь Cockpit + virt-manager), мониторинг, бэкапы
• br-production (VLAN 20) — продуктивные сервисы: 1С, TMS, WMS, AD
• br-dmz (VLAN 30) — DMZ: веб-серверы, почта, VPN

При создании ВМ указываем нужный bridge:

# Создание ВМ с подключением к production-сети
virt-install \
  --name erp-1c-server \
  --ram 32768 \
  --vcpus 8 \
  --os-variant ubuntu22.04 \
  --disk pool=ceph-vm-pool,size=200,format=raw,bus=virtio \
  --network bridge=br-production,model=virtio \
  --graphics vnc,listen=0.0.0.0 \
  --cdrom /iso/ubuntu-22.04-live-server-amd64.iso \
  --boot uefi

Для Windows-ВМ мы использовали VirtIO-драйверы, которые обеспечивали производительность дисков и сети на уровне паравиртуализации:

# Windows ВМ с VirtIO дисками и сетью
virt-install \
  --name win-ad-01 \
  --ram 16384 \
  --vcpus 4 \
  --os-variant win2k19 \
  --disk pool=ceph-vm-pool,size=100,format=raw,bus=virtio \
  --disk /iso/virtio-win.iso,device=cdrom \
  --network bridge=br-production,model=virtio \
  --graphics spice \
  --boot uefi

Процесс миграции 50 ВМ занял 4 недели. Мы разработали два сценария в зависимости от критичности:

Сценарий 1: Офлайн-конвертация (для некритичных ВМ). Выключаем ВМ на VMware, конвертируем диск, запускаем на KVM:

# Экспорт диска из VMware (OVF/VMDK)
# На VMware ESXi:
vim-cmd vmsvc/power.off vmid

# Конвертация VMDK → QCOW2
qemu-img convert -f vmdk -O qcow2 \
  vm-disk.vmdk \
  /var/lib/libvirt/images/vm-disk.qcow2

# Для Ceph — конвертация в RAW и импорт
qemu-img convert -f vmdk -O raw vm-disk.vmdk vm-disk.raw
rbd import vm-disk.raw vm-pool/erp-server-disk

# Создание ВМ из существующего диска
virt-install \
  --name erp-server \
  --ram 32768 \
  --vcpus 8 \
  --os-variant ubuntu22.04 \
  --import \
  --disk vol=ceph-vm-pool/erp-server-disk,bus=virtio \
  --network bridge=br-production,model=virtio \
  --boot uefi

Сценарий 2: Живая миграция через промежуточный этап (для критичных ВМ). Для 1С, AD, TMS — даунтайм не более 5 минут:

# 1. Создаём реплику данных на KVM
# 2. Останавливаем запись на VMware-ВМ
# 3. Финальная синхронизация данных
# 4. Переключаем DNS/IP на KVM-ВМ
# 5. Запускаем на KVM

# Для баз данных 1С использовали pg_basebackup:
pg_basebackup -h vmware-1c-server -D /var/lib/postgresql/15/main \
  -U replicator -Fp -Xs -P

# Синхронизация через streaming replication до момента переключения
# В postgresql.conf на KVM-сервере:
primary_conninfo = 'host=vmware-1c-server port=5432 user=replicator'
restore_command = 'cp /var/lib/postgresql/archive/%f %p'

Для Active Directory мы добавили новый контроллер домена на KVM-ВМ, дождались репликации, перенесли FSMO-роли и затем вывели старый контроллер из эксплуатации. Даунтайм AD — 0 минут.

Статистика миграции:

• 30 Linux-ВМ: средний даунтайм 8 минут (конвертация диска + первый запуск)
• 15 Windows-ВМ: средний даунтайм 15 минут (установка VirtIO-драйверов)
• 5 критичных ВМ (1С, AD, TMS, WMS, Exchange): максимальный даунтайм 4 минуты

После миграции мы настроили live migration между хостами KVM — аналог vMotion в VMware. Это позволяет перемещать работающую ВМ между физическими серверами без даунтайма — для обслуживания оборудования или балансировки нагрузки.

Предварительные требования:

• Общее хранилище (Ceph) — диски ВМ доступны со всех хостов
• Одинаковые модели CPU (или используем cpu mode='host-model')
• Сетевая связность между хостами по выделенной сети миграции

# Live migration ВМ с хоста 1 на хост 2
virsh migrate --live --persistent --undefinesource \
  erp-1c-server \
  qemu+ssh://kvm-host-02/system \
  --migrateuri tcp://10.10.2.12

# Мониторинг процесса миграции
virsh domjobinfo erp-1c-server
# Job type:         Unbounded
# Time elapsed:     12456 ms
# Data processed:   28.5 GiB
# Data remaining:   1.2 GiB
# Memory processed: 28.5 GiB
# Dirty rate:       245 pages/s
# Iteration:        3

# Установка лимита скорости миграции (чтобы не забить сеть)
virsh migrate-setspeed erp-1c-server 500  # 500 MiB/s

Снапшоты — одно из преимуществ KVM перед VMware в плане гибкости:

# Создание снапшота перед обновлением
virsh snapshot-create-as erp-1c-server \
  --name "before-update-2026-04" \
  --description "Before 1C platform update" \
  --atomic

# Список снапшотов
virsh snapshot-list erp-1c-server
# Name                    Creation Time               State
# before-update-2026-04   2026-04-01 10:00:00 +0300   running

# Откат к снапшоту (если обновление сломало что-то)
virsh snapshot-revert erp-1c-server before-update-2026-04

# Удаление снапшота (после подтверждения, что всё работает)
virsh snapshot-delete erp-1c-server before-update-2026-04

Для автоматического бэкапа мы написали скрипт, который создавал external snapshot, копировал диск и удалял snapshot:

#!/bin/bash
# backup_vm.sh — бэкап ВМ через external snapshot
VM_NAME=$1
DATE=$(date +%Y%m%d)
BACKUP_DIR=/backup/vms/${VM_NAME}

mkdir -p ${BACKUP_DIR}

# Создаём external snapshot (ВМ продолжает работать)
virsh snapshot-create-as ${VM_NAME} \
  --name backup-${DATE} \
  --disk-only \
  --atomic \
  --quiesce  # Сброс буферов гостевой ОС через qemu-guest-agent

# Копируем оригинальный диск (он заморожен)
rbd export vm-pool/${VM_NAME}-disk ${BACKUP_DIR}/${VM_NAME}-${DATE}.raw

# Коммитим изменения обратно и удаляем snapshot
virsh blockcommit ${VM_NAME} vda --active --pivot
virsh snapshot-delete ${VM_NAME} backup-${DATE} --metadata

echo "[$(date)] Backup ${VM_NAME} completed: ${BACKUP_DIR}" >> /var/log/vm-backup.log

После полной миграции мы провели сравнительное тестирование производительности и составили финальный отчёт:

Итоги проекта:

• Экономия — 12 миллионов рублей в год на лицензиях. Стоимость нашей работы окупилась за 3 недели.
• Производительность — на 2-5% выше благодаря меньшему overhead KVM и оптимизации VirtIO.
• Даунтайм миграции — суммарно 4.5 часа на все 50 ВМ (среднее 5 минут на ВМ).
• Обучение команды — 4 инженера прошли 3-дневный тренинг по KVM/libvirt/Ceph.
• Единственный минус — GUI управления (Cockpit) уступает vCenter по удобству. Но для команды, работающей через CLI и Ansible, это некритично.

Через 2 месяца эксплуатации ни одного инцидента, связанного с виртуализацией. Uptime — 99.99%. Если ваша компания рассматривает уход с VMware — команда itfresh.ru поможет спланировать и выполнить миграцию без потерь.