Миграция с VMware на Proxmox в 2026 году решается тремя способами: встроенным мастером импорта Proxmox VE 8.2+, экспортом OVF с конвертацией через qemu-img и через virt-v2v. Мастер — самый простой путь, для типовой миграции с ESXi и vSphere: жмете кнопки в веб-интерфейсе, ВМ переезжает по сети.
- OVF — ручной экспорт-импорт через файлы, для одной-двух ВМ когда мастер не подходит.
- virt-v2v — «умная» конвертация: сама добавляет в гостевую систему недостающие драйверы, для сложных случаев и Windows без virtio. Инструкция для сисадмина, который уже принял решение мигрировать и ищет рабочую процедуру с командами.
Безопасная миграция держится на четырех правилах: снимите снапшоты, сделайте независимый бэкап, удалите VMware Tools, поставьте virtio-драйверы в Windows ДО переноса. Без этого что-то обязательно сломается. Дальше — почему именно так и что делать на каждом шаге.
Когда и почему мигрируют с VMware на Proxmox
Что изменилось у VMware после Broadcom
После покупки Broadcom в конце 2023 года VMware свернула бессрочные лицензии — теперь только подписка. Стоимость владения у части корпоративных заказчиков выросла в 2–3 раза. С российского рынка VMware ушла: легальные продажи лицензий и техподдержка недоступны, обновления гипервизора блокируются. Параллельно — регуляторика: ФЗ-187 (КИИ), ФЗ-152 (ПДн), Приказ ФСТЭК № 117 для ГИС с 1 марта 2026 года.
Когда Proxmox действительно подходит, а когда нет
Proxmox — открытая платформа виртуализации. Подходит как замена для SMB и среднего бизнеса без обязательного реестра российского ПО, для команд с Linux-экспертизой и для dev/test-сред. Работает и в смешанной схеме: продакшн на сертифицированной российской платформе, разработка и QA — на Proxmox VE.
Не подходит для значимых объектов КИИ и государственных ИС — там по закону нужен сертифицированный российский продукт (zVirt, РЕД Виртуализация). И не лучшая идея для команды без опыта Linux: запустить можно, но первая нештатная ситуация превратится в долгий разбор по форумам.
Подготовка к переносу виртуальных машин: что сделать ДО миграции
Перенос виртуальных машин начинается с инвентаризации, а не с кнопки в мастере. Иначе на каждом втором проекте часть ВМ оказывается нельзя мигрировать «как есть».
Чек-лист до миграции
- Аудит парка на ESXi: версия гостевой ОС, размер дисков (включая тонкие диски, которые растут по мере записи), vCPU, RAM, особенности (RDM, vGPU, FT, NSX, UEFI или BIOS). По итогам — таблица «ВМ — особенности — риски», без нее план не строится.
- Независимый бэкап всех переносимых ВМ. Система резервного копирования должна быть готова заранее — на снапшоты ESXi полагаться нельзя: если миграция сломает диск, восстановить вы не сможете.
- Удаление снапшотов на исходных ВМ. Снапшот — «фотография» состояния ВМ; пока он активен, диск состоит из основного файла плюс цепочки изменений. Мастер эту цепочку не понимает: падает или тащит в 3–5 раз дольше.
- Установка virtio-драйверов в Windows ДО миграции. virtio — «общий язык» виртуального оборудования Proxmox/KVM. ESXi использует свой набор устройств; Windows на новой платформе должна знать virtio-net (сеть), virtio-scsi (диск), virtio-balloon (память) — иначе не загрузится. Драйверы — в ISO virtio-win.
- Удаление VMware Tools перед миграцией или сразу после первой загрузки. На Proxmox они бесполезны и иногда мешают — старые драйверы не отвечают.
- Целевой Proxmox VE 8.2+ кластер: хранилище (Ceph, NFS, ZFS, LVM-thin), сеть (Linux bridge/OVS), объём под ВМ.
- Сетевой доступ от Proxmox до ESXi (HTTPS на 443) и стабильная сеть 10/25 Gb — на медленной сети мастер не справится в разумное время.
Что чаще всего забывают
На большом парке полезен независимый аудит ИТ-инфраструктуры — он находит зависимости, которые внутри команды считаются очевидными и потому пропускаются. Если миграция совпала с обновлением железа — это уже импортозамещение серверного оборудования. Недоделанная подготовка — 80% проблем.
Способ 1. встроенный мастер импорта Proxmox VE 8.2+
vmware to proxmox через встроенный мастер — самый быстрый путь. С Proxmox VE 8.2 в веб-интерфейсе появился прямой импорт ВМ с ESXi по сети, без экспорта в OVF: кликнули, выбрали ВМ, переехала.
Минимум: Proxmox VE 8.2 (лучше 8.3), ESXi 6.5+ (Standalone или vCenter).
Шаги в мастере
- Datacenter → Storage → Add → ESXi → URL хоста, логин, пароль, отметка «verify certificate». Proxmox подцепляет ESXi как внешнее хранилище и видит его ВМ.
- Открыть добавленное хранилище ESXi → выбрать целевую ВМ → Import → задать целевое хранилище Proxmox, мост, имя ВМ → запустить.
- Сразу укажите формат целевого диска (qcow2 или raw), включите ISO virtio-win, выберите SCSI controller — VirtIO SCSI single. Это быстрый интерфейс; LSI медленнее в 2–3 раза.
Мастер сам конвертирует vmdk → qcow2/raw (как docx → odt — нужен перевод формата), переписывает .vmx-параметры в Proxmox-конфиг, создаёт ВМ в кластере.
Ограничения и время
ВМ должна быть выключена, мастер не работает с активными снапшотами, не переносит сетевые настройки гостя, MAC-адрес генерируется заново. Если мастер не подключается к ESXi — почти всегда это сертификат (выключите проверку для теста) или закрытый порт 443.
ВМ 100 ГБ переносится за 30–60 минут на сети 10 Gb, параллельно идут 5–10 ВМ. На 25 Gb — вдвое быстрее. Если физических узлов ещё нет — заранее подберите сервер под Proxmox VE с учётом требований к Ceph, кластерной сети и резервированию питания.
Способ 2: экспорт OVF и конвертация vmdk в qcow2
Конвертация vmdk в qcow2 через qemu-img нужна, когда мастер не подходит: Proxmox ниже 8.2, нет сетевого доступа до ESXi или вы переносите одну-две ВМ без настройки storage-плагина (это плагин Proxmox, подключающий ESXi как внешнее хранилище). Идея: экспортируете ВМ в файл, переносите на Proxmox, конвертируете в «родной» формат, привязываете как диск.
- Экспорт через ovftool (официальная утилита VMware): ovftool vi://root@esxi.local/MyVM /local/path/MyVM.ovf. Получится папка с .ovf (описание ВМ), .vmdk (диск), .mf (контрольные суммы).
- Копирование .vmdk на Proxmox-узел через scp или rsync по быстрой сети.
- Конвертация: qemu-img convert -f vmdk -O qcow2 MyVM-disk1.vmdk MyVM-disk1.qcow2. -f — исходный формат, -O — целевой. Для LVM-thin используйте -O raw — qcow2 там не поддерживается.
- Создание новой ВМ в Proxmox через веб-UI без диска. Привязка готового образа: qm importdisk <vmid> MyVM-disk1.qcow2 <storage> (qm — управление ВМ из командной строки).
- Финальная настройка: SCSI controller VirtIO, ISO virtio-win для Windows, проверка порядка загрузки и сети.
Подводные камни: qcow2 на LVM-thin не пишется (только raw); без virtio Windows даст синий экран; при нескольких дисках UUID разъезжаются — после привязки проверьте lsblk и при необходимости правьте /etc/fstab.
Способ 3: миграция через virt-v2v (proxmox v2v)
proxmox v2v через утилиту virt-v2v — для сложных случаев: Windows без virtio-драйверов, RHEL-семейство, автоматическое внедрение virtio в гостя. virt-v2v заглядывает внутрь гостевой ОС и сама добавляет недостающие драйверы — ставить их вручную не нужно.
virt-v2v копирует диски ВМ с ESXi/vCenter, конвертирует их в qcow2, инжектирует virtio в Windows-гость и virtio-модули в Linux-гость, регистрирует ВМ в Proxmox.
Установка: пакет libguestfs-tools на узле Proxmox или на отдельной машине-конвертере (предпочтительнее).
Команда: virt-v2v -ic vpx://user@vcenter.local/Datacenter/host -o local -os /var/lib/vz/images MyVM
Расшифровка: -ic — откуда забираем ВМ (vCenter), -o local -os — куда сохраняем диски, MyVM — имя исходной ВМ.
Преимущество: virt-v2v решает проблему virtio за вас, если команда впервые делает миграцию.
Ограничения: нужен доступ к ESXi/vCenter с правами Read-only; для ВМ больше 1 ТБ ставьте --io-mode native. Сетевые настройки гостя и MAC-адреса не сохраняются.
После миграции: проверка, virtio, удаление VMware Tools, нагрузочный тест
Гостевая ОС загрузилась — это только начало. Проверьте всё ниже, иначе сюрпризы вылезут уже под нагрузкой.
Что проверить сразу
- Первая загрузка: virtio-сеть и virtio-диск работают, гость загрузился без safe mode (если запустился в safe mode — virtio не подхватился), лог dmesg или Event Viewer без красных ошибок.
- Удаление VMware Tools, если не успели до миграции: Контрольная панель → Программы или apt remove open-vm-tools на Linux.
- Установка qemu-guest-agent — это «глаза и руки» Proxmox внутри ВМ: корректно гасит машину, делает консистентные снапшоты, показывает IP гостя. На Linux — apt install qemu-guest-agent, на Windows — из ISO virtio-win. Включите: свойства ВМ → Options → QEMU Guest Agent.
- Сеть: MAC-адрес может измениться, Windows определит новый интерфейс — перенастройте статический IP.
- Активация Windows: после смены MAC и виртуального железа система может потребовать повторную активацию. KMS обычно подхватывается автоматически; MAK-ключ нередко «слетает» — проверьте лицензии заранее.
- Кластерные функции: live migration (живая миграция ВМ между узлами без остановки) и HA-перезапуск при отключении узла.
Тестовая нагрузка
Перед переводом продакшн-трафика прогоните 24–48 часов на сопоставимом профиле: SQL-запросы, нагрузка от 1С, ночные бэкапы. Сравните CPU, память и диск с показателями на ESXi: расхождение больше 15% — проверьте SCSI controller, virtio и CPU type.
Особенности миграции кластера и больших объёмов
50+ ВМ: стратегия и приоритеты
Парк 50+ ВМ — другой класс задачи: параллельный мультипоток, разбивка по тизерам критичности, окно простоя только для критичных. Сначала переносят dev/test и внутренние сервисы, потом некритичный продуктив, в конце — ядро бизнеса. Так к критичным ВМ вы подходите с отлаженной процедурой.
Если Proxmox видит то же FC/iSCSI хранилище через мультипат — копирования по сети не нужно: переподключаете LUN, ребилдите метаданные, регистрируете ВМ. Терабайты не гоняются по сети.
Сеть и HA после переноса
Сетевая топология: переход с vDS (распределенный коммутатор VMware) на Linux Bridge или OVS делается заранее. Спроектируйте бриджи и VLAN-теги до миграции, не во время.
Live migration в Proxmox-кластере работает между узлами с одинаковыми CPU-флагами — гость переезжает «вживую». На смешанных CPU используйте профиль cpu type=qemu64 или kvm64 — потеря производительности есть, но миграция возможна.
С VMware HA на Proxmox HA: настройте кворум-устройство (механизм голосования при отказе узла), fence-агенты, политики перезапуска ВМ. Окно простоя для критичных ВМ — 10–30 минут: финальный холодный sync через rsync --write-only-data, остановка ВМ на ESXi, окончательный sync, запуск на Proxmox.
Типичные ошибки при миграции и как их избежать
- Активные снапшоты на ВМ. Мастер не понимает цепочку дельт — падает или висит часами. Решение: удалите снапшоты до миграции.
- INACCESSIBLE_BOOT_DEVICE в Windows. Причина: virtio-драйверы не установлены, Windows не понимает, на каком диске система. Решение: virtio-win ДО миграции; если уже мигрировали — временно через IDE/SATA, потом virtio, потом VirtIO SCSI.
- LSI вместо VirtIO SCSI single. Производительность диска проседает в 2–3 раза — LSI это эмуляция «древнего» контроллера. Решение: VirtIO SCSI single для новых ВМ.
- qcow2 на LVM-thin хранилище — формат не поддерживается. Решение: конвертируйте в raw.
- Сетевые настройки внутри гостя слетают из-за смены MAC-адреса. Решение: фиксируйте MAC при создании ВМ или правьте конфиг сети внутри гостя.
- ВМ с RDM, FT-режимом, NSX-T правилами — мастер их не перенесёт корректно, это специфические функции VMware. Решение: для них отдельный план миграции.
- Перегруз сети ESXi во время мультипоточного импорта 10+ ВМ. Может «положить» прод-трафик. Решение: ограничьте параллельные потоки.
- Несовпадение времени между узлами Proxmox и ESXi. Решение: NTP на обеих сторонах, иначе проверки сертификата и репликация снапшотов начинают сбоить.
Часто задаваемые вопросы (FAQ) о миграции с VMware на Proxmox
Можно ли мигрировать виртуальные машины без остановки сервиса?
Полностью «вживую» — нет: Proxmox не понимает работающую ESXi-ВМ, у них разные форматы. Минимизировать простой можно через предварительный sync дисков и финальный холодный sync — окно 10–30 минут.
Сколько времени занимает миграция одной ВМ 100 ГБ?
На сети 10 Gb типовая виртуальная машина переносится за 30–60 минут через мастер импорта. На 25 Gb — 15–30 минут. На 1 Gb — 2–4 часа, для продакшена это уже неприемлемо.
Что делать с гостевыми ОС Windows после миграции?
Поставить virtio-драйверы из ISO virtio-win — лучше до миграции. После: qemu-guest-agent, удаление VMware Tools, повторная настройка статического IP.
Какие версии ESXi поддерживает встроенный мастер Proxmox?
Официально 6.5 и новее. На практике 7.0 и 8.0 работают стабильнее всего. С 6.0 и старше идите через OVF.
Нужно ли удалять VMware Tools до или после миграции?
Лучше до. После миграции VMware Tools всё равно бесполезны — там нет VMware. Иногда мешают: старые драйверы не отвечают на запросы новой среды.
Как мигрировать ВМ с подключённым FC/iSCSI хранилищем?
Если Proxmox видит то же FC/iSCSI хранилище — переподключите LUN без копирования по сети. Создайте ВМ без диска, добавьте LUN: qm set <vmid> --scsi0 <storage>:<lun>.
Что делать, если после миграции ВМ не загружается?
Чаще всего проблема в SCSI controller или virtio. Загрузите ВМ с Live ISO в rescue, убедитесь, что диск виден, поменяйте controller на IDE/SATA, поставьте virtio, верните VirtIO SCSI.
Можно ли использовать Veeam для миграции вместо встроенных инструментов?
Да. Veeam Backup & Replication с 12.2+ восстанавливает копии напрямую на Proxmox VE. Удобно, если Veeam уже развернут.
