Введение
После приобретения VMware компанией Broadcom политика лицензирования кардинально изменилась. Бессрочные лицензии ушли в прошлое, им на смену пришли подписки с привязкой к пакету VCF (VMware Cloud Foundation). Для многих заказчиков стоимость владения выросла в два и даже три раза. Согласно прогнозам Gartner, к 2028 году 70 % корпоративных пользователей VMware перенесут не менее половины своих виртуальных нагрузок на другие платформы.
Но главная сложность при таком переходе — не техническая, а организационная. Как перенести работающие приложения, не остановив бизнес? Как избежать потери данных? В этом материале мы разберём три основных сценария:
остаться внутри экосистемы VMware и использовать родные утилиты;
перейти на открытые гипервизоры (KVM / Proxmox VE);
воспользоваться корпоративным решением на базе резервного копирования (Vinchin).
Для каждого варианта даны конкретные пошаговые инструкции и предостережения, основанные на реальной практике.
Нативные инструменты VMware (миграция внутри экосистемы)
Когда применять: замена оборудования, объединение vCenter, обновление vSphere.
Цель :не покидать VMware.
Краткий обзор инструментов
| Инструмент | Назначение | Простой | Ограничения |
| vMotion | Перенос вычислительных ресурсов | нулевой (миллисекунды) | требуется общее хранилище |
| Storage vMotion | Перенос хранилища | нулевой | только смена хранилища |
| HCX | Крупномасштабная миграция между сайтами/версиями | минуты (окно отключения) | дополнительная платная опция |
Пять шагов миграции с HCX (основной процесс)
1. Настройка сети между сайтами: развернуть сетку сервисов HCX. Критично:управляющая сеть, сеть vMotion и восходящие каналы должны быть связаны на L3, а MTU согласован (рекомендуется 9000). Иначе производительность репликации упадёт на 80 %.
2. Первоначальная полная синхронизация : с помощью «групп перемещения» выбрать ВМ и выполнить первое копирование на основе CBT (Change Block Tracking). Нагрузка на хранилище источника очень высокая – выполняйте только в часы спада и настройте ограничение I/O.
3. Постоянная инкрементальная синхронизация :с заданным RPO (обычно 5–30 мин) передаются только изменения; источник работает без помех.
4. Тестовое переключение :запустить ВМ в изолированной VLAN на целевой стороне и выполнить проверку. Не пропускайте этот шаг! Несовместимость политик портов dvSwitch (CDP/LLDP) приведёт к потере сети.
5. Финальное переключение ：после последней синхронизации выключить ВМ на источнике и активировать на целевой платформе. HCX поддерживает откат одним нажатием.
Важное ограничение: при миграции между vCenter с разными поколениями CPU обязательно проверьте совместимость режима EVC, иначе миграция завершится ошибкой.
Инструменты с открытым исходным кодом: VMware → KVM / Proxmox VE
Когда применять:переход на открытую виртуализацию для снижения затрат. В качестве примера рассмотрим самый частый сценарий VMware → Proxmox VE.
Основные инструменты
Встроенный мастер импорта Proxmox ：графический интерфейс, подходит для единичных или небольших партий (< 10 ВМ)
virt‑v2v: стандартный CLI-инструмент Linux, хорош для средних партий с автоматизацией
StarWind V2V Converter : лёгкий бесплатный GUI, для аварийных случаев
Пять шагов миграции и «грабли»
1. Оценка совместимости перед миграцией
Операционная система: Linux (CentOS/RHEL/Ubuntu) имеет встроенные драйверы VirtIO, адаптация проходит гладко. Windows Server — зона риска – без драйверов VirtIO после переноса вы получите синий экран 0x0000007B.
Режим загрузки: если источник использует UEFI, на целевой стороне надо выбрать OVMF (UEFI); ошибка с SeaBIOS приведёт к невозможности загрузки.
2. Импорт данных
Способ А (рекомендуется): мастер Proxmox подключается напрямую к vCenter/ESXi и потоково конвертирует VMDK → QCOW2.
Способ Б:экспорт через OVF Tool в файлы .ovf+.vmdk, затем импорт командой qm importdisk.
3. Адаптация виртуального оборудования (самый ответственный этап)
Контроллер диска: IDE → VirtIO SCSI
Сетевой адаптер: e1000 → VirtIO
Важно для Windows: перед сменой контроллера обязательно предварительно внедрить драйверы VirtIO (viostor.inf, netkvm.inf) через WinPE или DISM, иначе синий экран неизбежен.
4. Перенастройка сети
Запустить ВМ в изолированной сети, настроить IP и маршруты. Для CentOS 7/8 обратите внимание на predictable network naming имя интерфейса может измениться с eth0 на ens192, нужно править конфигурационные файлы.
5. Стратегия переключения
Используйте подход «сначала подготовить, потом переключить»: после успешной проверки в окно простоя выключите источник, измените VLAN на целевой стороне и перенаправьте трафик.
Границы применимости:нулевая стоимость, но нет визуального оркестратора, нет групп согласованности снимков, нет автоматического отката. Рекомендуемый размер партии до 50 ВМ, и только для некритичных систем, допускающих простой в часы.
Корпоративная миграция: решение Vinchin на основе резервного копирования
Когда применять:сотни ВМ, необходимо гарантировать нулевую потерю данных, наличие Windows vm, требуется GUI‑оркестрация и возможность отката.
Концепция: миграция через резервное копирование
Vinchin строит миграцию на основе уже существующих резервных копий. По сути, процесс это «восстановление» ранее сохранённой копии на целевую платформу. Любой сбой не страшен, потому что исходная резервная копия всегда доступна, и вы можете вернуться в исходную точку.
Ключевые возможности
| Возможность | Описание |
| Поддержка платформ | Более 20+ платформ: VMware, Hyper‑V, Proxmox, zVirt,POCA,HOSTVM,РЕД, Huawei, AWS, Huawei Cloud и др. |
| Без агентов | Не требуется устанавливать агенты внутрь ВМ, нет проблем с совместимостью |
| Мгновенное восстановление | Запуск ВМ на целевой платформе из копии за 15 секунд для быстрой проверки |
| Инкрементальная синхронизация | Периодическое резервное копирование на основе CBT, восстановление из любой точки во времени |
| Проверка целостности | Встроенная проверка данных после восстановления |
Процесс миграции (на примере VMware → Proxmox)
1. Подготовка: в веб‑консоли Vinchin добавить учётные данные источника (VMware) и цели (Proxmox); система автоматически обнаруживает ВМ.
2. Создание резервной копии источника: выбрать нужные ВМ, настроить политику (полная + инкрементальная) и запустить задачу.
3. Восстановление на целевую платформу: в списке копий выбрать любую точку восстановления, в мастере указать целевую платформу Proxmox; система автоматически конвертирует VMDK → QCOW2 и адаптирует виртуальное оборудование.
4. Проверка и переключение: запустить ВМ на Proxmox, проверить работу приложений, затем в окно простоя переключить трафик.
Матрица принятия решений
| Критерий | Нативные инструменты | Открытые инструменты | Vinchin (корпоративный) |
| Время простоя | секунды | минуты–часы | минуты |
| Кросс‑платформенность | ❌ | ✅ VMDK→QCOW2 | ✅ 20 + платформ |
| Защита данных | зависит от снимков | ❌ нет защиты во время миграции | ✅ резервная копия = защита |
| Поддержка Windows | ✅ нативная | ❌ требуется ручной ввод драйверов | ✅ автоматическая адаптация |
| Откат | зависит от снимков | отсутствует | восстановление из любой точки |
| Оркестрация | HCX поддерживает | требуется самостоятельное скриптирование | единая консоль |
| Сложность | высокая (требует экспертов по сети/хранилищам) | очень высокая (CLI + ручная работа с драйверами) | низкая (веб‑мастер) |
| Масштаб | любой | рекомендуется до 50 ВМ | любой |
Проверьте себя по трём вопросам
Куда двигаемся? Если внутри VMware, смело берите vMotion/HCX. Если в открытую платформу, где только Linux и допустим простой ,можно попробовать virt‑v2v. Если там есть Windows или требуется гарантия от сбоев ,выбирайте Vinchin.
Готовы ли рискнуть данными? Если нет ,только решение с резервным копированием.
Какой уровень экспертизы в команде? Если есть специалисты по ядру Linux и драйверам ,справятся с открытым стеком. Если команда занимается эксплуатацией ,корпоративный инструмент окупится за счёт снижения простоев.
Заключение
Воспринимайте миграцию не как рутинное «перетаскивание файлов», а как возможность пересмотреть архитектуру и сделать инфраструктуру более гибкой. Не существует одного «лучшего» инструмента — есть подходящий для ваших условий.
Десять пунктов перед стартом
Составлен ли полный реестр виртуальных машин (RVTools или API vCenter)?
Проверена ли производительность целевого хранилища (IOPS выше пиковых значений источника)?
Выявлены ли хосты ESXi, подключённые в обход vCenter?
Для Windows‑машин выполнена ли предварительная установка драйверов VirtIO?
Исключены ли RDM‑диски (прямое маппинг LUN) — их нужно преобразовать в обычные VMDK?
Не возникает ли конфликт IP‑адресов с существующими VPN или выделенными каналами?
Настроен ли мониторинг и оповещение для целевой среды?
Перенесены ли политики резервного копирования на новую платформу?
Разработана и утверждена ли процедура отката (SOP) с чёткими шагами?
Выделено ли время на пилотный проект (2 недели) с небольшим количеством ВМ?
Рекомендуемая стратегия
Тестовые и разработочные среды — используйте открытые утилиты, чтобы набраться опыта.
Обычные бизнес‑системы — применяйте корпоративное решение с защитой данных.
Ключевые продукты — обязательно делайте предварительный запуск через мгновенное восстановление и только после этого планируйте финальный переход.
Правильно подобранный инструмент даёт высокие шансы на успех, а строгий регламент исключает аварии. Начните с пилотного проекта и двигайтесь поэтапно.
