Руководство по миграции с VMware ESXi на Proxmox VE для предприятий

Предпосылки миграции и предварительные проверки соответствия

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

До начала технических работ рекомендуется выполнить две проверки соответствия:

1. Границы лицензирования VMware: условия лицензирования разных версий и каналов приобретения по-разному регулируют экспорт VMDK и использование на сторонних платформах. Рекомендуется перед массовым экспортом уточнить, покрывает ли текущая лицензия сценарий миграции.

2. Лицензирование ПО и политики безопасности: убедиться в соответствии лицензий операционных систем и стороннего ПО после миграции, а также в том, что новая платформа отвечает корпоративным требованиям безопасности.

 Ключевые различия в совместимости: 90% проблем при миграции возникает здесь

До начала миграции необходимо понимать различия между VMware и Proxmox на уровне основных компонентов, особенно для виртуальных машин Windows:

Как выбрать способ миграции?

Почему для производственных сред рекомендуется миграция на основе резервного копирования?

Традиционный подход отвечает на вопрос «как перенести файлы». Бизнес же спрашивает: «что делать, если миграция не удалась?» Модель миграции на основе резервного копирования создаёт для каждой ВМ полную резервную копию с подтверждённой возможностью восстановления ещё до начала любых операций преобразования — резервный образ служит одновременно носителем для миграции и гарантией отката.

 Четыре шага миграции

Шаг 1: Составление инвентаризации ВМ

Для каждой виртуальной машины, подлежащей миграции, необходимо зафиксировать: версию ОС, vCPU/память, типы контроллеров дисков и сетевых адаптеров, уровень критичности (критичный/обычный/тестовый), ответственного сотрудника.

Важное замечание: ВМ со снапшотами содержат несколько delta-файлов, что значительно повышает вероятность сбоя при преобразовании и риск аномального разрастания дискового пространства после миграции. Рекомендуется перед миграцией объединить снапшоты в единый файл диска.

Шаг 2: Создание проверяемой полной резервной копии

•  Создать полную резервную копию (не инкрементальную/дифференциальную) для каждой ВМ;

• Проверить возможность восстановления — не откладывать первую проверку на окно миграции;

• Хранить резервную копию на носителе, независимом от исходной и целевой систем.

Шаг 3: Предварительная настройка драйверов (особенно критично для Windows)

Для Windows ВМ порядок действий строг:

1.  Предварительная установка драйверов VirtIO: пока ВМ ещё работает на VMware, подключить ISO-образ с драйверами VirtIO и установить драйверы viostor (дисковый контроллер) и netkvm (сетевой адаптер);

2. Удаление VMware Tools: во избежание конфликтов с QEMU Guest Agent после миграции;

3. Установка QEMU Guest Agent после миграции: для получения IP-адресов, синхронизации времени и других функций управления.

Экстренное реагирование: если после миграции появляется синий экран с ошибкой INACCESSIBLE_BOOT_DEVICE, временно изменить шину диска на IDE/SATA → загрузить систему → установить драйверы VirtIO → выключить ВМ, вернуть шину на VirtIO SCSI → перезагрузить.

Для Linux ВМ ядра 5.x и новее уже содержат встроенные драйверы VirtIO. После миграции достаточно настроить диск и сетевой адаптер на VirtIO и установить  qemu-guest-agent. Для старых версий (RHEL/CentOS 7 и ниже) необходимо заранее загрузить модуль  virtio  в initramfs.

Шаг 4: Миграция в три этапа

• Первый этап (верификация): 2–3 тестовые/разработочные ВМ, наблюдение 2–3 рабочих дня;

• Второй этап (некритичные производства):файловые серверы, системы документооборота — услуги с контролируемым влиянием простоя;

• Третий этап (критические системы): базы данных, ERP, AD — стратегия «сначала резервирование, затем переключение».

  Два обязательных действия после миграции

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

• Диски и сетевые адаптеры должны использовать VirtIO — это базовая настройка производительности Proxmox;

• Для вычислительно интенсивных нагрузок установить тип CPU в  host;

• Политика кэширования хранилища выбирается комплексно, с учётом архитектуры, аппаратной конфигурации и требований к надёжности бизнеса — writeback повышает производительность записи, но требует наличия ИБП или RAID-контроллера с батарейной защитой; writethrough предпочтительнее в сценариях с высокими требованиями к целостности данных или при использовании сетевых хранилищ. Не рекомендуется принимать решение только на основе типа носителя (SSD/HDD).

2. Создание независимой системы резервного копирования и аварийного восстановления для Proxmox

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

 Почему для критических производственных сред требуется Vinchin?

Корпоративная миграция — это не перенос данных, а управление рисками. Vinchin Backup & Recovery предоставляет ключевые возможности в трёх аспектах:

1. Единая защита данных на кроссплатформенном уровне

В переходный период необходимо одновременно защищать VMware и Proxmox, избегая фрагментации управления. Vinchin поддерживает управление резервным копированием и восстановлением для VMware, Proxmox, Hyper-V и других сред виртуализации на единой платформе.

2. Верификация в изолированной среде перед миграцией

Поддерживается предварительное восстановление резервной копии в Proxmox в изолированной сети для функциональной верификации — это позволяет перенести риски сбоя миграции из производственной среды в тестовую.

3. Бесшовный переход к аварийному восстановлению после миграции

Сразу после ввода Proxmox в эксплуатацию активируются автоматическое резервное копирование, репликация на удалённые площадки и стратегии быстрого восстановления, что исключает «окно уязвимости» из-за задержек в развёртывании системы защиты.

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

В1: Что делать, если после миграции Windows выдаёт синий экран?

Временно изменить шину диска на IDE/SATA → загрузить систему → установить драйверы VirtIO → выключить ВМ, вернуть шину на VirtIO SCSI → перезагрузить.

В2: Возможна ли миграция без остановки?

Крайне сложно. Исключение составляют случаи, когда прикладной уровень сам поддерживает кластерное переключение. Для обычных сервисов рекомендуется запланировать окно остановки на 5–30 минут для финального переключения.

В3: Как мигрировать 100 ВМ без потери контроля?

Три принципа: поэтапность + автоматизация + стандартизация процессов. Избегать ручных операций для каждой ВМ.

В4: Можно ли сразу отключить старую среду VMware?

Не рекомендуется. Сохранять исходную среду VMware как минимум 2–4 недели в качестве финального варианта отката. Отключать старое оборудование только после подтверждения стабильности новой среды.

Заключение

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

✅ Предварительная проверка соответствия → ✅ Оценка совместимости → ✅ Полная инвентаризация активов → ✅ Проверяемая полная резервная копия → ✅ Подготовка драйверов и системы → ✅ Поэтапное выполнение → ✅ Настройка производительности → ✅ Создание системы аварийного восстановления

Для тестовых сред ручного преобразования достаточно. Для производственных сред миграция на основе резервного копирования — создание защитного слоя до миграции, использование резервных образов в качестве носителя, быстрое восстановление системы защиты после миграции — это проверенный на практике путь с низким уровнем риска.

 Более подробная информация о сценариях миграции с VMware на Proxmox с использованием Vinchin доступна на  официальном сайте Vinchin