-
Как выбрать способ миграции VMware в Proxmox?
-
Что проверить перед миграцией VMware в Proxmox?
-
Как выполнить миграцию VMware VM в Proxmox?
-
Как сократить простой и риски при миграции VMware в Proxmox?
-
Как проверить VMware VM после миграции в Proxmox?
-
Лучшие практики миграции VMware в Proxmox
-
Часто задаваемые вопросы о миграции VMware в Proxmox
-
Заключение
Все больше компаний рассматривают Proxmox VE в качестве альтернативы VMware. Поэтому миграция VMware в Proxmox становится актуальной задачей для многих ИТ-команд, которые планируют модернизацию или замену существующей виртуальной инфраструктуры.
Однако перенос виртуальных машин VMware в Proxmox — это не просто преобразование файла VMDK в другой формат. В производственной среде необходимо учитывать совместимость виртуального оборудования, драйверы VirtIO для Windows, настройки сети и хранилищ, целостность данных, возможный простой сервисов, а также возможность отката в случае проблем.
В зависимости от количества виртуальных машин, типа рабочих нагрузок, допустимого простоя и масштаба проекта можно использовать разные способы миграции: Proxmox Import Wizard, ручное преобразование VMDK в QCOW2 или миграцию на основе резервного копирования и восстановления.
В этой статье рассмотрим все три подхода, разберем подготовку к миграции VMware в Proxmox, способы снижения простоя и рисков, а также проверку виртуальных машин после переноса.

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

Proxmox Import Wizard
Для небольшого количества виртуальных машин с относительно простой конфигурацией Proxmox Import Wizard является одним из наиболее прямых способов миграции.
Такой подход позволяет сократить количество ручных операций: администратору не нужно самостоятельно выполнять все этапы создания ВМ, преобразования дисков и настройки виртуального оборудования.
Однако в крупных средах могут возникнуть дополнительные требования. Если инфраструктура включает большое количество ВМ, сложные сетевые настройки, несколько хранилищ или критически важные сервисы, одного Import Wizard может быть недостаточно.
В таких случаях необходимо учитывать не только перенос самой ВМ, но и возможность предварительного тестирования, восстановления и отката.
Ручное преобразование VMDK в QCOW2
Еще один распространенный вариант — получить виртуальные диски VMware в формате VMDK и преобразовать их в формат, используемый в Proxmox.
Для этого можно использовать qemu-img и другие инструменты QEMU.
Этот способ предоставляет администратору больше контроля над:
форматом виртуального диска;
BIOS/UEFI;
контроллером диска;
CPU и оперативной памятью;
сетевым адаптером;
целевым хранилищем;
параметрами загрузки ВМ.
Однако все эти параметры придется настраивать самостоятельно. Кроме того, необходимо отдельно решить вопросы с драйверами Windows, сетевой конфигурацией и загрузкой операционной системы.
Поэтому ручное преобразование VMDK в QCOW2 больше подходит администраторам, которые хорошо знакомы с VMware, Linux, QEMU и командной строкой Proxmox.
Миграция на основе резервного копирования
Для производственных сред можно использовать другой подход: сначала создать резервную копию виртуальной машины VMware, а затем восстановить ее в Proxmox.
Вместо прямой работы с исходным VMDK процесс выглядит следующим образом:
VMware → Резервная копия → Точка восстановления → Proxmox → Тестирование → Проверка → Переключение
Такой подход особенно полезен для:
критически важных виртуальных машин;
массовой миграции;
сред с жесткими требованиями к простою;
проектов, где необходимо предварительно протестировать результат;
инфраструктуры, в которой нужен четкий план отката.
Что учитывать при выборе инструмента миграции VMware в Proxmox?
Инструмент миграции VMware в Proxmox для производственной среды должен решать не только задачу переноса виртуальных дисков.
При выборе программного обеспечения стоит обратить внимание на следующие возможности:
поддержку VMware;
поддержку Proxmox VE;
перенос конфигурации ВМ;
перенос данных виртуальных дисков;
тестовое восстановление;
массовую миграцию;
настройку сетевых и дисковых соответствий;
работу с точками восстановления;
возможность отката.
Для production-среды такие возможности могут быть важнее, чем простая функция преобразования VMDK.
Что проверить перед миграцией VMware в Proxmox?
Успешная миграция VMware в Proxmox начинается не с выключения виртуальной машины, а с предварительной оценки инфраструктуры.
Для одной тестовой ВМ достаточно базовой проверки совместимости. Для production-среды рекомендуется заранее сформировать полный список виртуальных машин и проверить соответствие ресурсов и конфигурации целевой платформы.

Составьте список виртуальных машин
Перед началом миграции рекомендуется зафиксировать основные параметры каждой ВМ:
имя ВМ;
операционную систему;
количество CPU;
объем оперативной памяти;
количество и объем виртуальных дисков;
тип виртуальных дисков;
режим BIOS или UEFI;
сетевые адаптеры;
IP-адрес;
MAC-адрес;
VLAN;
используемое приложение;
зависимости от других систем.
Для крупных VMware-сред также важно документировать зависимости между виртуальными машинами.
Например, типичное корпоративное приложение может включать:
Web Server → Application Server → Database Server
Поэтому порядок миграции следует определять не только по количеству ВМ, но и с учетом зависимостей между сервисами.
Проверьте ресурсы VMware и Proxmox
Перед миграцией необходимо убедиться, что целевая инфраструктура Proxmox располагает достаточными ресурсами:
CPU;
оперативной памятью;
дисковым пространством;
пропускной способностью сети;
необходимыми VLAN;
подходящим режимом BIOS/UEFI;
совместимой конфигурацией виртуального оборудования.
Если используется миграция через резервное копирование, необходимо также проверить соединение системы резервного копирования с исходной VMware-инфраструктурой и целевой средой Proxmox.
Например, в среде Vinchin необходимо заранее проверить доступность необходимых интерфейсов управления и сетей передачи данных VMware и Proxmox. Это позволит избежать ситуации, когда резервная копия создается успешно, но восстановление на целевую платформу невозможно из-за сетевых ограничений.
Спланируйте соответствие сетей и хранилищ
VMware и Proxmox используют разные модели настройки виртуальной сети и хранилищ, поэтому соответствия лучше определить до начала миграции.
Например:
VMware Port Group → Proxmox Bridge/VLAN
и:
VMware Datastore → Proxmox Storage
Необходимо заранее проверить:
исходную сеть ВМ;
соответствующий Bridge в Proxmox;
VLAN ID;
IP-адреса;
Gateway;
DNS;
целевое хранилище;
доступный объем;
производительность хранилища.
Если этот этап пропустить, виртуальная машина может успешно загрузиться в Proxmox, но при этом приложение будет недоступно по сети.
Проверьте Snapshot VMware
Snapshot — один из элементов, который часто забывают проверить перед миграцией.
Перед переносом рекомендуется убедиться:
есть ли активные Snapshot;
корректно ли сформирована цепочка Snapshot;
нет ли слишком длинной цепочки;
доступны ли все необходимые файлы виртуального диска;
нет ли старых Snapshot, которые больше не нужны.
Сложная или поврежденная цепочка Snapshot может увеличить риски при преобразовании дисков и резервном копировании.
Поэтому перед производственной миграцией желательно удалить ненужные Snapshot и убедиться, что исходная ВМ находится в стабильном состоянии.
Подготовьте драйверы VirtIO для Windows
После переноса Windows VM из VMware в Proxmox виртуальное оборудование может измениться.
Например, виртуальный контроллер диска и сетевой адаптер в VMware отличаются от устройств VirtIO, которые обычно используются в Proxmox.
Поэтому до миграции Windows VM рекомендуется подготовить:
драйвер VirtIO для дисков;
драйвер VirtIO для сети;
QEMU Guest Agent;
план работы с VMware Tools.
Если необходимый драйвер хранения не установлен заранее, после переключения на другой виртуальный контроллер Windows может не загрузиться или перестать видеть системный диск.
Поэтому драйверы Windows необходимо подготовить до миграции, а не после первой неудачной загрузки виртуальной машины.
Как выполнить миграцию VMware VM в Proxmox?
После завершения предварительной проверки можно выбрать подходящий способ переноса виртуальной машины.
Способ 1. Миграция VMware VM с помощью Proxmox Import Wizard
Для относительно простых виртуальных машин можно использовать Proxmox Import Wizard.
Типичный процесс выглядит следующим образом:
Подготовка VMware VM → Подключение к хранилищу VMware → Импорт ВМ → Настройка оборудования → Запуск и проверка

Шаг 1. Подготовьте виртуальную машину VMware
Проверьте:
состояние питания;
Snapshot;
виртуальные диски;
сеть;
BIOS/UEFI;
операционную систему.
Если используется миграция с простоем, выключите исходную ВМ в согласованное окно обслуживания.
Шаг 2. Подключите хранилище VMware
Убедитесь, что Proxmox может получить доступ к хранилищу VMware, где находятся данные виртуальной машины, и прочитать необходимые файлы.
Шаг 3. Импортируйте виртуальную машину
В Proxmox выберите необходимую виртуальную машину и выполните импорт с помощью Import Wizard.
Шаг 4. Проверьте виртуальное оборудование
После импорта проверьте:
CPU;
оперативную память;
диски;
контроллер диска;
сетевой адаптер;
порядок загрузки.
Шаг 5. Запустите и проверьте ВМ
Запустите виртуальную машину и убедитесь, что операционная система, диски и сеть работают корректно.
Если Windows VM не загружается, в первую очередь проверьте режим BIOS/UEFI, контроллер диска и наличие драйверов VirtIO.
Способ 2. Преобразование VMDK в QCOW2 и импорт в Proxmox
Если требуется полный контроль над процессом, можно выполнить ручную миграцию.
Общий порядок:
Выключение ВМ → Получение VMDK → Преобразование диска → Создание ВМ в Proxmox → Импорт диска → Настройка оборудования → Запуск

Шаг 1. Выключите VM и получите VMDK
Сначала корректно выключите виртуальную машину VMware, чтобы обеспечить согласованное состояние дисков.
Затем скопируйте необходимые VMDK в среду, из которой они будут доступны Proxmox.
Если виртуальная машина использует несколько дисков, необходимо убедиться, что все нужные диски перенесены и их соответствие исходной конфигурации сохранено.
Шаг 2. Преобразуйте VMDK в QCOW2
Для преобразования VMDK в QCOW2 можно использовать утилиту qemu-img:
qemu-img convert -f vmdk source.vmdk -O qcow2 target.qcow2
Это один из наиболее распространенных способов конвертации VMDK в QCOW2 для последующего использования в Proxmox.
Для больших виртуальных дисков заранее проверьте свободное место на целевом хранилище и оцените время преобразования с учетом производительности дисковой подсистемы.
Важно понимать:
Преобразование VMDK — это только один этап миграции VMware в Proxmox.
После конвертации необходимо настроить виртуальное оборудование, контроллер диска, загрузку и сетевую конфигурацию целевой ВМ.
Шаг 3. Создайте виртуальную машину в Proxmox
Создайте ВМ с конфигурацией, максимально соответствующей исходной:
CPU;
RAM;
BIOS/UEFI;
Machine Type;
сеть.
Системный диск можно пока не добавлять, поскольку он будет импортирован на следующем этапе.
Шаг 4. Импортируйте диск
Для импорта преобразованного диска в целевое хранилище Proxmox можно использовать qm importdisk:
qm importdisk <VMID> target.qcow2 <storage>
После завершения операции добавьте импортированный диск к виртуальной машине и выберите подходящий контроллер диска.
Шаг 5. Запустите и проверьте ВМ
После запуска проверьте:
загрузку операционной системы;
системный диск;
дополнительные диски;
сетевой адаптер;
IP-конфигурацию;
работу приложений.
Для Windows VM отдельно убедитесь, что драйверы VirtIO установлены и работают корректно.
Способ 3. Миграция VMware в Proxmox с помощью Vinchin
Для производственных сред можно использовать Vinchin Backup & Recovery для миграции VMware VM в Proxmox через резервное копирование и восстановление.
В этом случае процесс не сводится к прямому копированию исходного VMDK:
Резервная копия VMware → Точка восстановления → Восстановление в Proxmox → Проверка → Переключение

Такой подход позволяет объединить защиту данных, тестирование, миграцию и возможность восстановления в одном процессе.
Шаг 1. Добавьте VMware-инфраструктуру
Добавьте среду VMware vSphere в Vinchin и укажите необходимые параметры подключения и учетные данные.
После добавления убедитесь, что виртуальная машина, которую необходимо перенести, корректно обнаруживается системой.
Шаг 2. Создайте резервную копию VMware VM
Выберите необходимую виртуальную машину и создайте задачу резервного копирования.
Для production-среды важно не ограничиваться проверкой статуса задания. Убедитесь, что созданная точка восстановления действительно пригодна для восстановления.
Шаг 3. Выберите точку восстановления
Выберите нужную точку восстановления и укажите Proxmox VE в качестве целевой платформы.
Это позволяет использовать заранее созданную копию данных вместо непосредственной работы с текущим состоянием исходной ВМ.
Шаг 4. Настройте целевую Proxmox VM
В зависимости от исходной конфигурации и ресурсов целевой среды настройте:
CPU;
RAM;
диски;
Storage;
сеть;
MAC-адрес;
другие параметры виртуального оборудования.
При восстановлении Vinchin использует API Proxmox VE для создания целевой виртуальной машины и восстановления данных на соответствующие виртуальные диски.
Шаг 5. Запустите и проверьте ВМ
После восстановления запустите виртуальную машину в Proxmox и проверьте:
операционную систему;
диски;
сеть;
приложения;
производительность.
До окончательного переключения производственной нагрузки можно сначала протестировать восстановленную ВМ и убедиться, что критические сервисы работают корректно.
Как сократить простой и риски при миграции VMware в Proxmox?
В тестовой среде неудачная миграция обычно является технической проблемой.
В production-среде ошибка при миграции может привести к остановке бизнес-сервисов.
Поэтому необходимо планировать не только сам перенос ВМ, но и весь процесс: тестирование, финальное переключение и откат.

Сколько времени занимает простой при миграции VMware в Proxmox?
Универсального значения простоя при миграции VMware в Proxmox не существует.
Продолжительность зависит от:
размера виртуальных дисков;
объема реально передаваемых данных;
пропускной способности сети;
производительности хранилища;
скорости изменения данных;
количества ВМ;
выбранного способа миграции;
возможности заранее передать данные;
необходимости финальной синхронизации.
Упрощенно время передачи можно представить так:
Время передачи ≈ Объем передаваемых данных ÷ Эффективная пропускная способность
Но важно различать общее время миграции и время простоя бизнеса.
Например, при ручной миграции весь процесс может выглядеть следующим образом:
Выключение → Копирование → Конвертация → Импорт → Настройка → Запуск
Если все операции выполняются только в рамках окна обслуживания, простой может быть значительным.
При использовании резервного копирования и предварительной передачи данных часть работ можно выполнить до отключения исходной ВМ. Тогда во время финального переключения остается только необходимый минимум операций.
Поэтому при планировании VMware to Proxmox downtime важно учитывать не только объем данных, но и то, какую часть миграции можно выполнить заранее.
Протестируйте рабочую нагрузку до финального переключения
Если выключить production VM в VMware и впервые запустить ее в Proxmox только после этого, проверка совместимости начнется уже во время простоя.
Более безопасный подход:
Backup → Test Recovery → Validate → Final Cutover
Можно заранее восстановить тестовую копию ВМ в Proxmox и проверить:
загрузку операционной системы;
доступность дисков;
сетевое подключение;
работу приложений;
критически важные бизнес-функции.
Так можно заранее обнаружить проблемы с драйверами VirtIO, сетевой конфигурацией, режимом загрузки и зависимостями приложений.
Подготовьте план Production Cutover
После успешного тестирования можно назначить финальное переключение.
Типичный порядок действий:
Определить окно обслуживания.
Остановить приложения.
Выключить исходную VM в VMware.
Выполнить финальное резервное копирование или подтвердить наличие актуальной точки восстановления.
Восстановить или перенести рабочую нагрузку в Proxmox.
Запустить Proxmox VM.
Проверить ОС и приложения.
Возобновить рабочий трафик.
Для баз данных и других приложений с высокими требованиями к согласованности данных необходимо дополнительно учитывать рекомендации разработчиков конкретного приложения.
Сохраните возможность отката
Не следует сразу удалять исходную VMware VM после первого успешного запуска в Proxmox.
До завершения периода проверки рекомендуется сохранить:
исходную VM;
финальную резервную копию;
рабочую точку восстановления;
сетевые и системные настройки;
документированную процедуру отката.
Если в Proxmox обнаружится критическая проблема, исходную среду или сохраненную точку восстановления можно использовать для возврата к рабочему состоянию.
Удалять исходную VMware VM стоит только после того, как новая среда прошла полную проверку и резервное копирование Proxmox VM работает корректно.
Выполняйте массовую миграцию поэтапно
Если необходимо перенести десятки или сотни виртуальных машин, не рекомендуется выполнять миграцию всей VMware-инфраструктуры одновременно.
Можно использовать следующую последовательность:
Pilot VM → Некритичные рабочие нагрузки → Обычные production VM → Критически важные сервисы
Сначала мигрируйте небольшое количество некритичных ВМ. После проверки сетевых настроек, драйверов, хранилищ и приложений постепенно увеличивайте масштаб.
Так крупный проект можно разделить на несколько управляемых этапов и снизить последствия возможной ошибки.
Как проверить VMware VM после миграции в Proxmox?
Успешная загрузка виртуальной машины еще не означает, что миграция завершена.
После переноса необходимо проверить виртуальное оборудование, сеть, приложения, производительность и резервное копирование.
Проверьте виртуальное оборудование
Убедитесь, что:
VM успешно запускается;
CPU и RAM настроены правильно;
системный диск определяется;
дополнительные диски доступны;
BIOS/UEFI настроен корректно;
контроллер диска выбран правильно;
драйверы VirtIO работают.
Для Windows VM также рекомендуется проверить Диспетчер устройств и убедиться, что отсутствуют неизвестные устройства или отсутствующие драйверы.
Проверьте сетевое подключение
Необходимо проверить:
IP-адрес;
MAC-адрес;
VLAN;
Proxmox Bridge;
Gateway;
DNS;
необходимые порты приложений.
Если VM загружается, но приложение недоступно, сетевые настройки следует проверить в первую очередь.
Проверьте приложения и сервисы
Проверка не должна ограничиваться операционной системой.
Необходимо убедиться в работоспособности:
Web-сервисов;
баз данных;
прикладных сервисов;
файловых ресурсов;
систем аутентификации;
планировщика задач;
внешних API;
зависимостей между приложениями.
Например, успешный запуск сервера базы данных еще не означает, что приложение может корректно подключиться к нему.
Проверьте производительность
После миграции следует некоторое время наблюдать за критически важными рабочими нагрузками.
Обратите внимание на:
загрузку CPU;
использование памяти;
дисковый I/O;
сетевой трафик;
время отклика приложений.
Если производительность заметно снизилась, следует проверить контроллер виртуального диска, тип Storage, настройки CPU и драйверы VirtIO.
Проверьте новое резервное копирование
После переноса VM в Proxmox нельзя автоматически считать, что прежняя политика резервного копирования VMware продолжает защищать новую ВМ.
Необходимо создать новую задачу резервного копирования для Proxmox VM и выполнить как минимум одну проверку восстановления:
Proxmox VM → Backup → Recovery Test
Для production-среды успешное резервное копирование и подтвержденное восстановление должны быть одними из условий окончательного вывода исходной VMware VM из эксплуатации.
Лучшие практики миграции VMware в Proxmox
Чтобы снизить риски при переносе виртуальной инфраструктуры, рекомендуется придерживаться следующих правил:
| Практика | Зачем это нужно |
|---|---|
| Создайте полный VM Inventory | Чтобы не пропустить ВМ или зависимости |
| Проверьте и очистите ненужные Snapshot | Чтобы снизить сложность работы с дисками |
| Проверьте ресурсы Proxmox | Чтобы избежать нехватки CPU, RAM и Storage |
| Заранее спланируйте сетевые соответствия | Чтобы избежать проблем после миграции |
| Подготовьте VirtIO для Windows | Чтобы снизить риск проблем с загрузкой |
| Создайте и проверьте резервную копию | Чтобы иметь надежную точку восстановления |
| Выполните тестовое восстановление | Чтобы выявить проблемы до Cutover |
| Выполняйте крупную миграцию поэтапно | Чтобы ограничить масштаб возможной ошибки |
| Сохраните исходные VM и Recovery Point | Чтобы обеспечить возможность отката |
| Настройте резервное копирование Proxmox | Чтобы продолжить защиту рабочих нагрузок |
| Проведите тест восстановления | Чтобы подтвердить реальную работоспособность Backup |
Главный принцип:
Не следует считать миграцию успешной только потому, что виртуальная машина загрузилась.
Полный процесс миграции VMware в Proxmox должен включать:
Assessment → Preparation → Backup → Migration → Validation → Rollback Readiness → Protection
Часто задаваемые вопросы о миграции VMware в Proxmox
1.Какой инструмент лучше всего подходит для миграции VMware в Proxmox?
Универсального инструмента, который будет оптимальным для всех сред, нет.
Для небольшого количества простых ВМ может быть достаточно Proxmox Import Wizard. Если нужен полный контроль над дисками, можно использовать инструменты преобразования VMDK.
Для production-среды стоит дополнительно учитывать поддержку резервного копирования, тестового восстановления, массовой миграции и отката.
Как преобразовать VMDK в QCOW2 для Proxmox?
Для этого можно использовать qemu-img:
qemu-img convert -f vmdk source.vmdk -O qcow2 target.qcow2
После преобразования диск необходимо импортировать в Proxmox VM и настроить контроллер диска, режим загрузки и сеть.
Сколько времени занимает миграция VMware в Proxmox?
Фиксированного времени нет.
Продолжительность зависит от размера виртуальных дисков, объема данных, сетевой пропускной способности, производительности Storage и выбранного способа миграции.
При этом общее время переноса не равно времени простоя. Предварительная передача данных и тестирование позволяют сократить период, в течение которого производственная система недоступна.
Как выполнить массовую миграцию VMware VM в Proxmox?
При большом количестве виртуальных машин рекомендуется сначала выполнить Pilot Migration на нескольких некритичных ВМ.
После проверки процесса можно поэтапно переносить production-нагрузки.
Если в инфраструктуре уже используется система резервного копирования, миграция через Recovery Point может упростить тестирование, восстановление и планирование отката.
Можно ли откатить миграцию VMware в Proxmox?
Да, если сценарий отката был подготовлен заранее.
До завершения проверки рекомендуется сохранить исходную VMware VM, финальную резервную копию и рабочую точку восстановления.
Не следует удалять исходную VM сразу после первого успешного запуска в Proxmox.
Заключение
Миграция VMware в Proxmox — это не просто преобразование VMDK в другой формат. В производственной среде главная задача заключается в том, чтобы безопасно перенести рабочие нагрузки на новую виртуализационную платформу, уложиться в допустимый простой и сохранить возможность восстановления в случае непредвиденных проблем.
Для небольшого количества простых виртуальных машин Proxmox Import Wizard может быть наиболее прямым вариантом. Если требуется полный контроль над виртуальными дисками и оборудованием, можно использовать ручное преобразование VMDK в QCOW2. Для production-сред, крупных проектов и критически важных рабочих нагрузок стоит рассмотреть миграцию на основе резервного копирования и восстановления.
Независимо от выбранного метода рекомендуется придерживаться последовательности:
Assess → Backup → Test → Migrate → Validate → Protect
Миграция считается действительно завершенной только после того, как виртуальные машины в Proxmox прошли проверку на уровне ОС и приложений, для них настроено новое резервное копирование, а восстановление данных было успешно протестировано.
Нужен более безопасный способ миграции VMware VM в Proxmox?
Для производственной среды миграция — это не только перенос данных виртуальной машины. Надежный процесс должен включать резервное копирование, восстановление, тестирование и возможность отката.
Vinchin Backup & Recovery поддерживает среды VMware и Proxmox и помогает защитить рабочие нагрузки перед миграцией, а при необходимости восстановить их на целевой виртуализационной платформе.