Как без стресса мигрировать ВМ с VMware/Hyper-V на KVM: пошаговый сценарий
Миграция «боевых» виртуальных машин — головная боль для любого админа: простой, риск потерь, страх «не откатиться».
Если вам предстоит…:
…переехать с VMware/Hyper-V на KVM без даунтайма критичных сервисов,
…убедиться, что новая инфраструктура запускается и работает так же надёжно,
…минимизировать простой и риски потери данных,
…иметь возможность быстро вернуть всё обратно, если что-то пошло не так,
то эта статья для вас.
Кто сталкивается обычно с подобными задачами:
Системные администраторы и DevOps при миграции инфраструктуры из локального ЦОД или другого облака на KVM.
Инженеры, которым нужно избавиться от дорогих лицензий и перейти на open source-стек.
IT-руководители, которым важно протестировать новую платформу без угрозы бизнесу.
Примеры из нашей практики:
— Компания-разработчик ПО решила переехать с Hyper-V на KVM, чтобы избавиться от привязки к вендору и платить только за ресурсы. Сначала мигрировали тестовую среду, потом поэтапно — продакшн. Благодаря сохранению копии ВМ и поэтапному запуску новых машин удалось избежать простоев и экстренных откатов.
Как сделать в Cloupard миграцию ВМ с VMware/Hyper-V на KVM
Вот что нужно подготовить и сделать, чтобы миграция прошла гладко.
1. Подготовка: создаём резервную копию ВМ
Перед любыми действиями — делаем копию виртуальной машины.
В панели управления KVM выбираем нужный диск и жмём «Сохранить копию ВМ в библиотеке».
Задаём имя файла, жмём OK — появится сообщение, что диск будет скопирован и размещён в библиотеке. После копирования скачиваем получившийся файл с расширением .qcow2.
Важно: это и есть ваш надёжный способ отката — в любой момент можно развернуть исходную ВМ из этой копии.
2. Экспортируем и конвертируем виртуальные диски
Экспортируйте диск из VMware/Hyper-V в формате, поддерживаемом KVM (.vmdk, .vhd, .vhdx).
Используйте утилиту virt-v2v для преобразования диска в .qcow2.
После конвертации — загрузите новый .qcow2 через библиотеку в Cloupard (через раздел «Elastic Cloud KVM — Библиотека»).
Далее создайте новую виртуальную машину, используя ваш загруженный образ.
3. Настройка и запуск ВМ в KVM
После загрузки образа создайте ВМ через панель управления или Terraform.
Укажите параметры: имя, регион, тип машины (базовая, универсальная, с графическим адаптером и т.д.).
Подключите к ВМ виртуальную сеть — либо существующую, либо создайте новую (через Elastic Cloud KVM — Виртуальные сети — Добавить).
Добавьте внешние IP-адреса и настройте NAT, если требуется интернет-доступ.
4. Проверка и тестирование
Запускайте ВМ, подключайтесь по SSH (необходим IP и пароль root, выдается при создании ВМ).
Для гибкости сценария используйте Ansible-скрипты для массового развёртывания и первичной настройки новых ВМ (инструкция в KB по Ansible не детализирована, но можно автоматизировать штатные действия через API/интерфейс).
5. Откат (Rollback) при необходимости
Если тесты не пройдены — удалите проблемную ВМ и разверните исходную копию из библиотеки (раздел «Библиотека», выбираете .qcow2 и разворачиваете новую машину на том же образе).
6. Финальный переход
После успешного тестирования перенаправьте трафик на новые ВМ в KVM, закройте старые сервисы.
По желанию — удалите резервные копии для экономии места.
Альтернативные пути
— Миграция с минимальными изменениями: если инфраструктура большая, сначала «поднимают» только сервисы 2–3 класса B, остальные подключают позднее.
— Для ускорения используют групповое создание ВМ через шаблоны и автоматизацию.
Итог для пользователя
Что получает клиент:
Переезд без потери данных, с минимальным простоем.
Возможность оперативно откатиться к предыдущей версии ВМ.
Гибкая настройка сетей, IP и ресурсов для каждой ВМ.
Расширяемость за счёт шаблонов и автоматизации.
Нет зависимости от вендора — дальнейшее развитие инфраструктуры на KVM свободно.
Ограничения:
Для работы с сетью и IP-адресами требуется ручная настройка в некоторых сценариях.
Поддержка rollback только при наличии свежей копии ВМ в библиотеке.
Автоматизация средствами Ansible возможна, но требует собственной подготовки playbook'ов (в KB нет готовых шаблонов).
Что дальше:
Рекомендуем после миграции протестировать аварийное восстановление из резервных копий, закрепить автоматизацию (Ansible, Terraform) для рутинных задач, регулярно обновлять контрольные точки в библиотеке.