VMware больше не вариант: план перехода на Proxmox без остановки прода

MAATRIX

Для части российских пользователей VMware перестала быть рабочим вариантом не по техническим причинам, а по организационным: продлить лицензию, оплатить подписку или получить поддержку стало невозможно или крайне дорого. Инфраструктура при этом продолжает работать — просто без права на обновления и без гарантии, что завтра всё не остановится разом. Переход на Proxmox VE решает эту проблему, но пугает одним словом — «простой». На практике грамотно спланированная миграция проходит без остановки прода вообще, если разбить её на этапы и не пытаться перенести всё одним вечером. Разберём этот план по шагам.

Инвентаризация: с чего начинается любая безопасная миграция

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

• Список ВМ с параметрами: vCPU, память, объём и тип дисков (thin/thick provisioning), используемый гипервизор (ESXi версии, если хостов несколько — с разными версиями прошивки это отдельная головная боль).
• Сетевые зависимости: к каким portgroup/vSwitch привязана каждая ВМ, какие VLAN используются, есть ли статические маршруты или NAT-правила, завязанные на конкретный IP хоста.
• Зависимости между сервисами: какая ВМ ходит в какую базу, какие сервисы дергают друг друга по внутренним адресам, где зашиты hardcoded IP вместо DNS-имён — это вскроется в момент переключения сети, и лучше найти это заранее, а не в проде.
• Расписания и интеграции: cron-задачи, бэкап-джобы, мониторинг, лицензии ПО, привязанные к MAC-адресу или serial номеру виртуального железа (такое встречается чаще, чем кажется, и после миграции лицензия может просто перестать активироваться).
• RDM-диски и проброшенные устройства (raw device mapping, USB-донглы, PCI passthrough) — для них нет прямого аналога «конвертации», и план под них нужен отдельный, часто на замену устройства или его виртуализацию заново уже на стороне Proxmox.

Результат этого шага — таблица с колонками: ВМ, критичность (можно остановить на час / нельзя останавливать вообще / нельзя терять данные даже на минуту), зависимости, допустимое окно простоя. Именно эта таблица дальше определяет порядок переноса — не алфавитный и не по вкусу, а по реальному риску.

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

Тестовая миграция: сначала некритичные ВМ

Дальше — соблазн сразу взяться за самую важную систему, потому что «время поджимает». Это ровно та ошибка, которая превращает контролируемую миграцию в аварийное восстановление. Правильный порядок обратный: сначала переносится то, что можно сломать без последствий для бизнеса.

Возьмите 1-2 некритичные ВМ — тестовый стенд, staging-окружение, внутренний инструмент без внешних пользователей — и прогоните на них весь процесс целиком: от выключения на VMware до первого успешного запуска на Proxmox и проверки сети. Цель этого шага не «перенести быстро», а зафиксировать реальный runbook:

• сколько времени фактически занимает конвертация диска такого размера на вашем железе (не ориентируйтесь на чужие цифры — тесты у всех идут с разной скоростью хранилища и сети, у вас будет своё значение);
• какие драйверы понадобилось доустановить в гостевую ОС, чтобы она увидела диск и сеть под KVM;
• какие мелочи не были учтены в инвентаризации (обычно всплывает 2-3 неожиданности даже после аккуратного аудита).

После первого прогона runbook дорабатывается, и уже с ним переходите к следующей партии — чуть более значимым системам, но всё ещё не к боевой базе данных или API, который нельзя ронять. Каждая волна проверяет процесс на всё более критичной нагрузке, пока вы не убедитесь, что план стабилен.

Если ваша цель — не только сменить платформу, но и разобраться с самой Proxmox с нуля, базовый разбор установки и первой виртуалки есть здесь: Proxmox VE с нуля: первая виртуалка за 20 минут.

Конвертация дисков: из VMDK в форматы Proxmox

Формат диска VMware (VMDK) и формат, с которым штатно работает Proxmox (QCOW2 или RAW поверх ZFS/LVM/Ceph — в зависимости от выбранного типа хранилища), физически разные контейнеры. Прямое копирование файла не работает — нужна конвертация. Есть два практических пути.

Вариант 1 — встроенный импорт из ESXi. У Proxmox VE есть мастер импорта, который умеет подключаться напрямую к хосту или кластеру ESXi по его API, показывать список доступных ВМ и импортировать выбранную сразу с конвертацией диска и переносом части конфигурации (память, vCPU, сетевые адаптеры сопоставляются по возможности автоматически). Это самый быстрый путь для типовых ВМ без экзотических устройств — но перед использованием стоит свериться с актуальной документацией именно той версии Proxmox, которая у вас установлена: возможности мастера меняются между релизами, и не все версии ESXi поддерживаются одинаково.

Вариант 2 — ручная конвертация через qemu-img. Универсальный путь, который работает всегда, независимо от версии ESXi и наличия сетевого доступа к vCenter:

qemu-img convert -f vmdk -O qcow2 disk-from-vmware.vmdk disk-for-proxmox.qcow2

Здесь -f — исходный формат, -O — целевой. Перед конвертацией обязательно проверьте на исходной стороне:

• Снапшоты консолидированы. Если у ВМ на VMware есть незакрытые снапшоты, экспортированный VMDK может не содержать актуального состояния диска — снапшот-цепочку нужно свести (consolidate) до конвертации, иначе рискуете перенести устаревшие данные.
• Тип диска. Thick-provisioned диски конвертируются предсказуемо, thin-provisioned — тоже, но итоговый размер результата может отличаться от ожидаемого, если исходный образ фрагментирован.
• Место на диске под конвертацию. На время операции нужно как минимум столько же свободного места, сколько занимает исходный образ, часто больше.

После конвертации диска гостевая ОС всё ещё «думает», что работает на контроллере VMware (LSI Logic/PVSCSI) и адаптере VMXNET3 — а видит она уже virtio-устройства KVM. Если в системе заранее не установлены virtio-драйверы, итог — либо ОС не грузится, либо не видит сеть после первого старта. Этот момент — самая частая причина провала подобных миграций, и в деталях (отдельно для Windows и Linux) он разобран здесь: миграция между гипервизорами: KVM, Xen, VMware. Если у вас есть Windows-гости — прочитайте этот материал перед переносом первой боевой ВМ, а не после первого BSOD.

Сеть и хранилище: готовим целевую инфраструктуру заранее

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

• Сетевые мосты (vmbr) на Proxmox, соответствующие тем же VLAN и подсетям, что использовались на VMware-стороне. Задача — чтобы перенесённая ВМ после смены гипервизора получила тот же IP и тот же VLAN, без необходимости менять сетевую конфигурацию внутри гостя. Если раньше не настраивали мосты и VLAN в Proxmox, стоит заранее разобрать типовые грабли: сеть в Proxmox: мосты, VLAN и почему пропал доступ — там же разобрана ситуация, когда неправильная правка моста на боевом хосте обрывает доступ к самому хосту управления.
• Хранилище — определитесь заранее, куда лягут диски: локальный LVM/ZFS, или сетевое хранилище (NFS, Ceph, iSCSI), если у вас несколько узлов Proxmox и нужна возможность live-миграции между ними уже внутри новой инфраструктуры. Тип хранилища влияет на то, какие форматы диска доступны — не все backend'ы поддерживают QCOW2 напрямую.
• Резервное копирование с первого дня. Перенесённая на Proxmox ВМ должна сразу попасть в контур бэкапов, а не оказаться единственной копией данных до следующего планового цикла. Если ещё не разворачивали Proxmox Backup Server — это стоит сделать до, а не после переноса боевых систем: Proxmox Backup Server: настройка и восстановление на практике.

Отдельно проверьте firewall-правила: если на VMware фильтрация трафика была на уровне NSX или отдельного файрвол-хоста, на стороне Proxmox эти правила придётся воссоздать явно — автоматического переноса политик между платформами нет.

Поэтапный перенос с сохранением возможности отката

Когда runbook обкатан на тестовых ВМ, а целевая инфраструктура готова, начинается перенос боевых систем — волнами, а не одним действием. Рабочая стратегия:

1. Не выключайте и не удаляйте исходную ВМ на VMware сразу после переноса. Погасите её, но оставьте на месте (или в архиве) на заранее оговорённый срок — обычно от нескольких дней до пары недель, в зависимости от критичности сервиса. Пока лицензия VMware ещё действует или хост физически доступен, у вас есть путь назад без восстановления из бэкапа.
2. Переносите системы в порядке возрастания риска: сначала внутренние сервисы без внешних пользователей, затем системы с некритичными данными, и только в конце — то, что нельзя ронять или терять. К моменту переноса самого важного у вас уже будет отработанный процесс и список типовых проблем именно вашей инфраструктуры.
3. Для систем с состоянием (базы данных, очереди) минимизируйте окно рассинхронизации. Полностью «живой» перенос между разными гипервизорами обычно недоступен — платформа виртуализации меняется, и на время конвертации диска гостевая ОС должна быть остановлена. Но можно сократить фактический даунтайм: например, для баз данных — настроить репликацию на новый инстанс заранее и на момент переключения только остановить запись, дождаться синхронизации хвоста и переключить трафик, вместо полного цикла «выключить — сконвертировать диск — включить».
4. Фиксируйте точку невозврата для каждой волны. До какого момента откат — это просто «включить обратно старую ВМ», и после какого момента откат уже требует восстановления новых данных, записанных уже на Proxmox-стороне (например, если в новую БД успели записаться свежие транзакции). Явный план отхода назад для каждого шага — не формальность: план отката миграции: что подготовить заранее разбирает именно эту логику на общих кейсах, и её стоит применить и здесь.
5. После каждой волны — контрольная проверка, а не «вроде запустилось, идём дальше»: доступность сервиса снаружи, целостность данных, работающие интеграции, cron-задачи на новом месте. Чек-лист таких проверок пригодится: как проверить, что миграция прошла успешно.

Финальное переключение сетевой инфраструктуры

Последний и самый заметный для пользователей шаг — переключение трафика с VMware-инфраструктуры на Proxmox. К этому моменту почти вся подготовительная работа уже сделана, и сам cutover должен занимать минуты, а не часы:

• Снизьте TTL у DNS-записей заранее (за сутки-двое до переключения), если переключение подразумевает смену IP — иначе часть клиентов продолжит стучаться по старому адресу ещё долго после отключения исходной системы из-за кеширования DNS.
• Если IP-адреса переносятся один в один (что часто возможно, если новая инфраструктура физически в той же сети или подсеть просто перенастраивается на новых хостах) — переключение сводится к остановке ВМ на VMware и запуску уже готовой, синхронизированной копии на Proxmox с тем же адресом. Это самый предсказуемый сценарий с точки зрения клиентов и внешних интеграций.
• Обновите записи на балансировщике или реверс-прокси, если он есть перед сервисами — часто именно эта точка, а не сама ВМ, определяет фактический момент переключения трафика.
• Держите старую сетевую инфраструктуру VMware (portgroup, vSwitch) выключенной, но не удалённой до истечения оговорённого окна отката — это тот же принцип, что и с самими ВМ: возможность откатиться должна стоить дешевле, чем последствия несостоявшегося отката.
• Мониторьте первые часы после переключения отдельно и внимательно: ошибки 5xx, всплеск задержек, разрывы соединений с базой — типичные симптомы того, что где-то осталась зависимость на старый IP или порт, пропущенная на этапе инвентаризации.

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

Частые вопросы