Миграция ВМ в 2026: пошаговые инструкции для vSphere, Hyper-V и KVM — Live и Cold Migration

Миграция виртуальных машин - это критическая операция для системного администратора или DevOps инженера. Неправильный подход приводит к длительным простоям, потере данных и нестабильности сервисов. Эта статья предоставляет универсальный пошаговый алгоритм и чек-листы для безопасного переноса рабочей нагрузки между популярными гипервизорами: VMware vSphere, Microsoft Hyper-V и KVM. Вы получите четкое понимание двух ключевых методов - Live Migration (без простоя) и Cold Migration - и сможете выбрать оптимальный для вашего сценария, минимизируя риски и исключая ошибки.

Что вы получите из этого руководства:

Готовые команды CLI для конвертации дисков: qemu-img convert переводит VMDK и VHDX в QCOW2, а маршрут VMDK → VHDX для Hyper-V разобран отдельно, с учётом ограничений конвертеров.
Чек-лист проверки совместимости CPU, дисков и сетевых драйверов перед миграцией.
Пошаговые инструкции для vMotion (Live Migration) в vSphere и для Live Migration через Move-VM в Hyper-V.
Практическое руководство по миграции на KVM с использованием libvirt и virsh.
План финальной проверки и отката, чтобы избежать «тихого сбоя» после переноса.

Мы фокусируемся на практических, проверенных шагах, которые работают в реальных условиях. Инструкции адаптированы для каждой платформы и включают команды CLI, настройки интерфейсов и проверки совместимости. Это готовый план действий, который вы можете применять сегодня.

В этой статье вы найдете:

Выбор стратегии: Live Migration или Cold Migration.
Универсальный чек-лист подготовки.
Пошаговую инструкцию для VMware vSphere.
Пошаговую инструкцию для Microsoft Hyper-V.
Пошаговую инструкцию для KVM.
Проверку работоспособности и план отката.
Особенности версий ПО к 2026 году.

Live vs Cold Migration: выбираем стратегию для вашего сценария

Успех миграции зависит от правильного выбора метода переноса. Live Migration обеспечивает нулевой простой, но требует специфичных условий. Cold Migration универсальна, но предполагает остановку сервисов. Ваш выбор определяется допустимым временем простоя, критичностью ВМ и совместимостью инфраструктуры.

Live Migration: как обеспечить нулевой простой критичных сервисов

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

Технические предпосылки для Live Migration:

Общее хранилище: ВМ должна находиться на сетевом хранилище (SAN, vSAN, кластер NFS/iSCSI), доступном для исходного и целевого хоста. В среде VMware это называется vMotion.
Совместимость процессоров: Хосты должны иметь совместимые наборы инструкций CPU (например, одинаковые флаги SSE, AVX). В vSphere это обеспечивается EVC (Enhanced vMotion Compatibility), в Hyper-V - аналогичными функциями кластеризации.
Стабильная высокоскоростная сеть: Для передачи состояния памяти требуется выделенная сеть с низкой латентностью и высокой пропускной способностью (минимум 1 Gbps, лучше 10 Gbps).

Практические кейсы применения Live Migration:

Плановое обслуживание или обновление гипервизора без остановки сервисов.
Балансировка нагрузки в кластере для распределения ресурсов.
Аварийное восстановление при выходе из строя одного хоста в кластере высокой доступности.

При выполнении длительных операций миграции через CLI рекомендуется использовать инструменты для устойчивых терминальных сессий, такие как tmux или screen, чтобы избежать прерывания процесса при обрыве SSH-соединения.

Cold Migration: когда остановка ВМ - это правильное решение

Cold Migration - это процесс переноса виртуальной машины в остановленном состоянии. ВМ выключается, её файлы (диски, конфигурация) копируются на новый хост или хранилище, затем машина запускается на целевой стороне.

Это единственный вариант в следующих сценариях:

Миграция между гипервизорами разных вендоров (например, из vSphere на KVM или из Hyper-V на vSphere).
Смена типа хранилища (например, переход с локального диска на сетевое хранилище, не поддерживающее одновременный доступ).
Отсутствие поддержки Live Migration в инфраструктуре (например, в простых конфигурациях без кластеризации).
Несовместимость оборудования (разные поколения CPU, отсутствие общей сети для vMotion).

Преимущество Cold Migration - универсальность и меньшие требования к совместимости инфраструктуры. Главный недостаток - простой сервиса. Время простоя можно оценить по формуле: (Объем данных виртуальных дисков / Скорость сети) + Время загрузки операционной системы внутри ВМ. Для ВМ с дисками объемом 100 ГБ и скоростью сети 1 Gbps (~100 MB/s) перенос файлов займет примерно 1000 секунд (17 минут). Добавьте время на остановку, запуск и проверку сервисов.

Алгоритм выбора метода:

Определите допустимое время простоя для сервисов на этой ВМ. Если оно равно нулю - оцените возможность Live Migration.
Проверьте совместимость инфраструктуры: общее хранилище, совместимость CPU, наличие выделенной сети для миграции.
Если условия для Live Migration не выполняются или ВМ не критична к простою, используйте Cold Migration.

Универсальный чек-лист подготовки: что проверить перед любой миграцией

Перед запуском миграции выполните системные проверки. Этот чек-лист минимизирует риск ошибок "не сработало в моем случае" и служит страховкой для всех платформ.

Анализ совместимости компонентов: процессоры, диски и сеть

Совместимость - самый частый источник проблем при миграции между разными гипервизорами или даже между версиями одного продукта.

CPU: Проверьте флаги процессоров исходного и целевого хоста. Для Linux хостов используйте команду cat /proc/cpuinfo | grep flags. Особое внимание - поддержка виртуализации (vmx для Intel, svm для AMD) и наборы инструкций (SSE, AVX). При миграции между разными вендорами (Intel -> AMD) или поколениями могут возникнуть проблемы.
Диски: Определите формат виртуального диска (VMDK для VMware, VHD/VHDX для Hyper-V, QCOW2/RAW для KVM). Планируйте конвертацию форматов при необходимости. Проверьте тип контроллера диска внутри ВМ (IDE, SCSI, SATA, VirtIO). После миграции на другой гипервизор может потребоваться изменение драйверов в гостевой ОС.
Сеть: Запланируйте смену MAC-адресов виртуальных сетевых адаптеров, если они жестко зафиксированы в конфигурации (например, в DHCP сервере). Проверьте доступность требуемых VLAN на целевой стороне. Тип сетевого драйвера (e1000, vmxnet3, VirtIO) также влияет на совместимость.

При миграции между географически распределенными дата-центрами или VPS проверьте реальную физическую локацию серверов и качество сетевого канала между ними. Нестабильная или медленная сеть сделает Cold Migration долгим и рискованным.

Создание точки отката: стратегии резервного копирования перед миграцией

Гарантированная точка восстановления - ваша "подушка безопасности". Не начинайте миграцию без нее.

Снимки (snapshots) на исходном гипервизоре: Быстро создаются и позволяют мгновенно откатиться к предыдущему состоянию ВМ. Однако это не полная замена бэкапа, особенно при миграции между разными платформами. Снимки могут быть не перенесены или не импортированы.
Экспорт ВМ в OVF/OVA: Это универсальный формат для переноса, поддерживаемый многими гипервизорами. Экспорт создает полный набор файлов ВМ (диски, конфигурация), который можно импортировать на другой гипервизор. Это надежный способ создания резервной копии для миграции.
Полное копирование файлов ВМ на внешнее хранилище: Скопируйте все файлы виртуальной машины (диски, конфигурационные файлы) на отдельный NAS или другой сервер с помощью инструментов типа rsync или scp. Проверьте целостность копии (например, сравните размеры файлов или выполните проверку через qemu-img check для дисков QCOW2).

Чек-лист в виде таблицы:

Область проверки	Контрольные пункты
Источник и цель	Версии гипервизоров, архитектура CPU (x86-64?), доступная RAM на целевом хосте, свободное место на хранилище цели.
Виртуальная машина	Формат диска, тип контроллера диска, тип сетевого адаптера, наличие специфичных драйверов (например, VMware Tools), привязка к лицензиям или оборудованию.
Сетевое окружение	IP-адресация (статическая/DHCP), имя хоста внутри ВМ, правила фаервола на исходном и целевом хостах, доступность необходимых портов.
Резервное копирование	Создана и проверена актуальная резервная копия ВМ и данных внутри нее (например, через экспорт в OVF или файловый бэкап).

Для комплексного понимания процесса миграции и управления рисками, ознакомьтесь с нашей статьей "Миграция IT-инфраструктуры: практические сценарии и ключевые триггеры для DevOps и системных администраторов", где разбираются бизнес-триггеры и типы миграций.

Пошаговые инструкции для каждой платформы

Это ядро статьи - готовые инструкции для vSphere, Hyper-V и KVM. Следуйте шагам последовательно.

Миграция в среде VMware vSphere: от vMotion до конвертера

В vSphere доступны штатные методы миграции и кросс-платформенные инструменты.

Live Migration (vMotion): В vSphere Client выберите ВМ, правой кнопкой -> Migrate. Выберите "Change host only" для миграции между хостами в кластере с общим хранилищем. Убедитесь, что vMotion сеть настроена и включена на хостах.
Cold Migration через интерфейс: Выберите ВМ, правой кнопкой -> Migrate. Выберите "Change datastore" для переноса на другое хранилище или "Change host and datastore" для переноса на другой хост с другим хранилищем. Это требует остановки ВМ.
Использование VMware vCenter Converter Standalone: Этот инструмент предназначен для миграции физических серверов или ВМ других гипервизоров в vSphere. Он конвертирует диски и адаптирует драйверы. После установки Converter создайте новую задачу импорта, указав источник (например, удаленный Hyper-V сервер) и цель (vSphere). Конвертер обработает драйверы внутри гостевой ОС.

Перед запуском vMotion проверьте:

Базовую линию EVC настроили и она одинакова на исходном и целевом хостах - иначе миграция завершится ошибкой совместимости CPU.
VMkernel-адаптер с включённой службой vMotion есть на обоих хостах, адресация между ними доступна (проверьте vmkping).
Общее хранилище (vSAN, SAN, NFS/iSCSI) подключено к обоим хостам, свободного места на цели достаточно.
Снапшоты ВМ удалены или отсутствуют: они увеличивают время миграции и усложняют откат.

После запуска ВМ на новом хосте:

ВМ отвечает по сети, а в vCenter нет активных ошибок в Events и vmkernel.log.
VMware Tools в гостевой ОС работает, статус - Running (при необходимости переустановите Tools).
Сетевые адаптеры подключены к нужным port groups, MAC-адреса и VLAN совпадают с планом.

Перенос виртуальных машин в Microsoft Hyper-V

Hyper-V предоставляет встроенные средства для экспорта/импорта и Live Migration в кластере.

Экспорт/Импорт ВМ: В Hyper-V Manager выберите ВМ, правой кнопкой -> Export. Укажите путь для экспорта. На целевой хосте в Hyper-V Manager выберите Import Virtual Machine и выберите экспортированную машину. Альтернативно используйте PowerShell: Export-VM -Name "VMName" -Path "C:\ExportPath" и Import-VM -Path "C:\ExportPath".
Live Migration в Hyper-V: Для работы требуется кластер Hyper-V с совместимостью CPU. Настройте миграцию через Failover Cluster Manager или PowerShell (Move-VM). Убедитесь, что для Live Migration настроена аутентификация (Kerberos или CredSSP): без неё Move-VM завершается ошибкой доступа.
Конвертация дисков: Для перехода из VMDK (VMware) в VHDX (Hyper-V) не полагайтесь на qemu-img: писать VHDX умеют не все сборки, поэтому конвертацию выполняют внешним V2V-конвертером (например, StarWind V2V Converter) или штатными средствами импорта Hyper-V. Обратное направление VHDX -> QCOW2 закрывается qemu-img: qemu-img convert -f vhdx -O qcow2 source.vhdx target.qcow2. Если диск уже в формате VHD, переведите его в VHDX штатной командой Hyper-V: Convert-VHD -Path C:\vm\disk.vhd -DestinationPath C:\vm\disk.vhdx.

Перед запуском:

Оба хоста видят общее хранилище: CSV, SMB 3.x, iSCSI или NFS.
Для Live Migration включена аутентификация Kerberos или CredSSP, нужные порты открыты в фаерволе.
На целевом хосте хватает RAM, дискового места, а версия конфигурации ВМ совместима с версией Windows Server.
У ВМ нет забытых контрольных точек (checkpoints): они копируются при экспорте и мешают откату.

После запуска:

Сетевой адаптер ВМ привязан к нужному виртуальному коммутатору, IP-адрес доступен по сети.
Integration Services (в новых версиях - гостевые компоненты) работают, в Event Viewer нет ошибок драйверов.
Проверены лицензии ПО внутри гостевой ОС и вручную назначенные MAC-адреса.

Миграция на KVM (QEMU): работа с CLI и виртуализацией на Linux

Администрирование KVM преимущественно происходит через командную строку. Ключевые инструменты - libvirt и virsh.

Конвертация дисков: Используйте qemu-img для преобразования форматов. Пример конвертации VMDK в QCOW2: qemu-img convert -f vmdk -O qcow2 source.vmdk target.qcow2. Для VHDX в QCOW2: qemu-img convert -f vhdx -O qcow2 source.vhdx target.qcow2. После конвертации проверьте результат командами qemu-img check target.qcow2 и qemu-img info target.qcow2.
Создание конфигурационного XML-файла для libvirt: Libvirt управляет ВМ через XML-файлы. Создайте базовый файл или экспортируйте конфигурацию из существующей ВМ с помощью virsh dumpxml VMName. Ключевые секции: память (<memory>), CPU (<vcpu>), диск (<disk> с указанием пути к конвертированному файлу), сеть (<interface>). Проверить корректность XML до запуска можно командой virt-xml-validate config.xml.
Импорт ВМ: Определите ВМ в libvirt: virsh define /path/to/config.xml. Затем запустите её: virsh start VMName.
Настройка Live Migration в кластере KVM: Для миграции между хостами KVM с общим хранилищем используйте команду virsh migrate --live VMName qemu+ssh://target_host/system. Убедитесь, что SSH доступ настроен между хостами, а на целевом хосте определены те же сети libvirt.

Перед запуском:

В гостевой ОС заранее установлены драйверы VirtIO: при переключении контроллера диска или сетевого адаптера с IDE/e1000 на VirtIO без них ВМ не загрузится.
XML прошёл валидацию, в нём нет ссылок на несуществующие файлы дисков, ISO и bridge-интерфейсы.
Целевой хост видит то же хранилище (NFS/iSCSI) и те же сети libvirt (bridge или Open vSwitch), MAC-адреса не конфликтуют.
Между хостами работает SSH по ключам и открыты порты live migration (по умолчанию 49152-49216 или диапазон из qemu.conf).

После запуска:

ВМ получила IP-адрес, сетевой адаптер внутри гостевой ОС определился без ошибок.
Команды virsh dominfo, virsh domstate и virsh domblklist показывают ожидаемое состояние и пути к дискам.
В логах libvirt (/var/log/libvirt/qemu/) и в dmesg на хосте нет ошибок ввода-вывода.

Если нужен готовый сервер виртуализации на KVM, посмотрите практическое руководство по сборке и настройке Proxmox VE или XCP-ng в 2026 году.

Универсальный алгоритм этапов:

Этап подготовки (Pre-flight check): Выполните чек-лист из предыдущего раздела.
Этап экспорта/конвертации: Для vSphere - экспорт в OVF через vCenter или использование VMware Converter. Для Hyper-V - экспорт ВМ через Hyper-V Manager или PowerShell. Для KVM - конвертация дисков (qemu-img) и подготовка XML конфигурации.
Этап переноса данных: Переместите файлы ВМ на целевой хост. Используйте scp, rsync по SSH или копирование через общее хранилище (NFS). Для устойчивости терминальных сессий при длительном копировании можно использовать Mosh или Eternal Terminal.
Этап импорта и настройки на целевом хосте: Импортируйте ВМ на целевой гипервизор (см. инструкции выше). Настройте сеть, проверьте конфигурацию.
Финальное переключение (Cut-over): Для Cold Migration - остановите ВМ на источнике, запустите на цели. Для Live Migration - процесс выполняется автоматически. Проверьте сервисы.

Финальное переключение и проверка работоспособности

После запуска ВМ на целевом хосте необходимо убедиться, что миграция успешна и сервисы работают корректно. "Тихий сбой" - когда ВМ запустилась, но функциональность нарушена - это распространенная проблема.

Последовательность действий для проверки:

Базовая проверка: Убедитесь, что ВМ доступна по сети (используйте ping на её IP-адрес). Проверьте, что операционная система загрузилась без ошибок (наблюдайте через консоль гипервизора или подключитесь сразу после запуска).
Проверка сервисов: Подключитесь к ВМ по RDP (для Windows), SSH (для Linux) или VNC. Проверьте системные логи (/var/log/syslog, Event Viewer) на наличие ошибок, связанных с драйверами или сетью. Выполните тестовые запросы к критичным сервисам (веб-сервер, база данных). Для быстрой проверки с мобильного устройства можно использовать универсальные клиенты, объединяющие SSH, VNC и RDP.
Мониторинг производительности: В первые часы после миграции наблюдайте за нагрузкой на CPU, память и диск внутри ВМ через инструменты гипервизора (vSphere Performance Charts, Hyper-V Performance Monitor, virt-top для KVM). Необычно высокая нагрузка может указывать на проблемы с драйверами или конфигурацией.
План отката: Заранее определите условия для возврата на исходный хост. Например: "Если ключевой сервис не отвечает более 5 минут после запуска" или "Если в логах обнаружены критичные ошибки драйверов". Шаги отката: остановить ВМ на цели, восстановить её из резервной копии на исходном хосте, запустить. Держите резервную копию доступной до окончательной стабилизации.

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

Базовые принципы миграции остаются неизменными, но платформы виртуализации развиваются. К 2026 году следует учитывать следующие тренды и изменения в новых версиях ПО.

VMware vSphere: В версии 8.x и выше продолжается развитие vMotion с улучшениями в производительности и поддержке новых форматов дисков (например, увеличенная поддержка NVMe). Enhanced vMotion Compatibility (EVC) расширяет возможности кластеров с разнородными CPU. При миграции с более старых версий (6.x/7.x) на 8.x проверьте базовую линию EVC и версию виртуального оборудования ВМ: слишком старые версии требуют апгрейда перед переносом, а форматы дисков - проверки на совместимость.
Microsoft Hyper-V: Развитие Azure Stack HCI влияет на миграционные сценарии для гибридных сред. Инструменты экспорта/импорта и Live Migration в Windows Server 2025 и далее остаются ключевыми, но могут появиться новые форматы интеграции с Azure. При миграции из standalone Hyper-V на Azure Stack HCI проверьте требования к кластеризации и версию конфигурации ВМ - при переносе на более новый хост её придётся обновлять.
KVM/QEMU/libvirt: Используйте актуальные стабильные ветки (QEMU 8.x и новее вместе с соответствующей версией libvirt): в них улучшена многопоточная передача памяти для Live Migration, что снижает время переноса больших ВМ, и расширена поддержка форматов дисков. Перед конвертацией проверьте, что qemu-img на целевом хосте понимает формат источника - список поддерживаемых форматов выводится в конце справки qemu-img --help.

Отдельное предупреждение по форматам дисков: перед переносом убедитесь, что целевая платформа читает формат источника нативно либо что конвертация выполнена и проверена (qemu-img check, qemu-img info). Не переносите диск в формате, который целевой гипервизор поддерживает только для чтения.

Общий совет: всегда сверяйтесь с официальной документацией для конкретных версий вашего гипервизора (VMware, Microsoft, дистрибутива Linux с KVM). Эта статья служит проверенным структурным каркасом и источником практических шагов, но детали могут меняться с выходом новых релизов.

И ещё одно: зафиксируйте план миграции во внутренней wiki - список ВМ, целевые хосты, ответственных, окно простоя и условия отката. Такой документ при разборе инцидента экономит больше времени, чем любой генератор отчётов, и сразу показывает, что и когда менялось в инфраструктуре.

Дополнительные материалы: