Серверная виртуализация

Миграция виртуальных машин: live migration, V2V и P2V

Как выбрать перенос VM между хостами и платформами или преобразование физического сервера в VM: простой, совместимость, риски и план отката.

14 минут
абстрактная иллюстрация переноса виртуальной инфраструктуры между серверами
Для переноса работающей VM внутри совместимой платформы выбирают Live Migration; если условия несовместимы или допустимо окно работ — холодную миграцию. При смене гипервизора нужна V2V-конвертация, а для переноса установленной системы с физического сервера — P2V. Минимальный простой зависит не только от выбранной функции, но и от CPU, хранилища, сети, гостевой ОС, приложения и прав на использование функций платформы.

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

Выбор метода по исходному состоянию нагрузки и цели переноса

МетодЧто переноситсяСостояние исходной системыТипичный простойКлючевые предварительные условияОсновные рискиКогда не выбирать
Live Migration внутри одной платформыСостояние выполнения, память и размещение VM; диски могут оставаться на общем хранилище или переноситься отдельной операциейГостевая ОС продолжает работать, но при финальном переключении обычно кратко приостанавливаетсяКороткая пауза на переключении; соединения приложения могут пережить её не во всех сетях и приложенияхСовместимые хосты, CPU и виртуальное оборудование, сеть миграции, доступное хранилище, запас ресурсов, разрешённая функцияОтказ операции из-за CPU, сети, datastore, устройства VM, политики кластера или лицензированияПри разных гипервизорах, неподдерживаемых устройствах, несовместимых CPU либо когда платформа не допускает операцию
Холодная миграцияВыключенная VM: конфигурация, виртуальные диски и связанные файлыVM выключенаОт остановки до запуска и проверки на цели; зависит главным образом от объёма данных и скорости переносаОкно простоя, совместимые форматы или средство преобразования, место на целевом хранилище, корректная сеть на целиНезагрузка гостя, несовместимый контроллер или формат диска, потеря сетевой связности после запускаКогда простой недопустим и есть подтверждённо совместимый сценарий Live Migration
V2VДиски и конфигурация существующей VM с преобразованием под другой гипервизорОбычно исходную VM останавливают на финальном переносе; конкретный конвертер может поддерживать иной режим только для отдельных сценариевЧасто включает время конвертации, запуска и исправления конфигурации гостяПоддерживаемая пара исходной и целевой платформ, форматы дисков, режим загрузки, драйверы, целевое виртуальное оборудованиеНесовместимость BIOS/UEFI, Secure Boot, контроллеров, драйверов, гостевых инструментов и лицензий ПОЕсли задача сводится к перемещению VM между совместимыми хостами одного кластера
P2VОС, приложения, данные и настройки физического сервера в новую VMФизический сервер обычно работает до финальной синхронизации или остановки; порядок определяет выбранный инструмент и приложениеЗависит от согласования данных, финального копирования, переключения сети и проверки сервисаДопустимое окно, согласованность данных, поддержка гостевой ОС, отсутствие критической зависимости от физических устройств, права на лицензииНесогласованные данные, не загружающаяся ОС, лишние физические драйверы, конфликт IP/имени, привязка ПО к оборудованиюКогда приложение требует неподдерживаемого физического PCIe-устройства, аппаратного ключа или лицензии, не допускающей виртуализацию

Live Migration — класс операций, а не обещание «миграции без простоя». Виртуальная машина продолжает исполняться во время основной части переноса, однако на финальном этапе платформа синхронизирует последние изменения и кратко останавливает выполнение. Длительная пауза или отказ возможны при высокой скорости изменения памяти, нехватке пропускной способности, проблемах с хранилищем либо при нарушении условий совместимости.

Миграция не заменяет HA, репликацию и резервное копирование

Live Migration предназначена прежде всего для планового перемещения нагрузки. Она не является автоматическим восстановлением после отказа хоста, не равна Hyper-V Replica и не создаёт резервную копию. План восстановления и актуальная резервная копия нужны независимо от наличия миграции.

vMotion и Storage vMotion в VMware

vMotion — название VMware vSphere для переноса включённой VM между хостами ESXi. В типичном сценарии vMotion переносит вычислительное состояние VM на другой хост, а её файлы остаются на datastore, доступном обоим хостам. Это термин VMware: не следует называть так Live Migration в Hyper-V, KVM или другой платформе.

Storage vMotion переносит файлы и виртуальные диски работающей VM между datastore без обязательной смены хоста. Поэтому задача «освободить хранилище» не обязательно требует vMotion, а задача «вывести хост в обслуживание» не всегда требует переноса дисков. Форматы дисков, например VMDK, при этом остаются в экосистеме VMware, если не выполняется отдельная V2V-конвертация.

Требования и лицензирование VMware зависят от релиза

Для vMotion и Storage vMotion сверяйте именно документацию и лицензионные права выбранного релиза vSphere/Broadcom и приобретённого пакета или действующего entitlement. Доступность функции определяется не одним наличием ESXi: она может зависеть от vCenter Server, редакции или подписки, состава лицензируемых компонентов и архитектуры. Условия прежних бессрочных лицензий, пробных редакций и современных пакетов нельзя переносить друг на друга. Контекст моделей поставки и прав на функции — в статье «Лицензирование VMware vSphere, ESXi и vCenter».

Официальная документация VMware для конкретного релиза требует проверять совместимость процессоров и доступность общего набора CPU-функций. Если хосты используют процессоры разных поколений одного производителя, может применяться EVC, но он не делает совместимой произвольную пару CPU и не исправляет несовместимость других компонентов. Также проверяют версию виртуального оборудования VM, доступность VMkernel-сети миграции, сопоставление сетей VM, доступность datastore по выбранной архитектуре и ограничения назначенных устройств.

  • Общее хранилище. Для обычного vMotion исходный и целевой хост должны иметь доступ к файлам VM на совместимом datastore. При переносе хранилища требования меняются: свободное место и доступность целевого datastore проверяются отдельно.
  • Сеть. Нужна связность интерфейсов VMkernel, выделенных для vMotion, и достаточная пропускная способность. Для VM важно соответствие целевой Port Group, VLAN и внешней сети.
  • CPU и VM. Проверяют совместимость CPU или режим EVC, версию виртуального оборудования и ограничения VM: passthrough-устройства, отдельные виртуальные устройства, vGPU, nested virtualization и другие функции могут ограничивать миграцию. Особенности passthrough рассматриваются в статье «GPU passthrough и вложенная виртуализация».
  • Ресурсы и правила. На цели должны быть CPU, память и разрешённое размещение с учётом affinity-правил, политик и состояния кластера.

Если vMotion не работает при наличии двух хостов, это ещё не указывает на одну конкретную причину. Обычно проблема относится к совместимости CPU или виртуального оборудования, VMkernel-сети, видимости datastore, сопоставлению сетей VM, свободным ресурсам, ограничениям устройств VM, правам либо доступности функции. Точный текст события и его время фиксируют до изменений; разбор конкретных ошибок — в диагностике проблем виртуальных машин и гипервизоров.

Hyper-V Live Migration и Storage Migration

В Microsoft Hyper-V Live Migration — собственное название переноса выполняемой VM на другой совместимый Hyper-V-хост. Storage Migration в Hyper-V переносит конфигурацию и файлы VM в другое расположение хранения без обязательной смены хоста. Это сходные по назначению, но не полностью взаимозаменяемые с VMware механизмы: отличаются поддерживаемые версии Windows Server, настройка аутентификации, требования к сети, хранению, кластеру и виртуальным коммутаторам.

Перед Hyper-V Live Migration в поддерживаемой версии Windows Server проверяют наличие роли Hyper-V на обоих хостах, совместимость процессоров либо включённый и поддерживаемый режим совместимости процессоров, сетевую связность и аутентификацию между хостами, соответствие виртуальных коммутаторов, целевое размещение файлов и ресурсы. Для Storage Migration отдельно проверяют доступность источника и цели, свободную ёмкость и права на пути хранения. Детальная настройка, кластер, Replica и высокая доступность вынесены в «Hyper-V Live Migration, Storage Migration, Replica и высокая доступность».

Когда нужна холодная миграция и как оценить простой

Холодная миграция уместна, когда Live Migration недоступна, не поддерживается для конкретной VM, не проходит предварительную проверку или когда согласованное окно простоя безопаснее риска отказа в рабочее время. Выключение VM не отменяет проверку формата дисков, виртуальных контроллеров, сети, режима BIOS/UEFI и загрузки Guest OS на целевом хосте.

Оцените окно простоя до начала миграции

Расчёт строят по фактической операции на некритичной копии или тестовой VM с сопоставимым объёмом данных, а не по скорости сетевого интерфейса на бумаге.

  1. 1
    Зафиксируйте границу простоя
    Определите момент, когда приложение перестаёт принимать записи, и момент, когда пользователи могут безопасно работать на цели. Ожидаемый результат — согласованное с владельцем приложения окно, а не только время копирования диска. Если такой границы нет, сначала определите процедуру согласования данных приложения.
  2. 2
    Разделите работу на этапы
    Учтите остановку или приостановку нагрузки, финальное копирование либо конвертацию, изменение конфигурации, загрузку гостевой ОС, старт сервисов и функциональную проверку. Для каждого этапа укажите измеряемое ожидаемое время. Если точной оценки нет, проведите пробную миграцию на сопоставимом объёме.
  3. 3
    Добавьте резерв на отказ и возврат
    В план включите время на остановку неудачной операции, возврат сетевого маршрута на исходную систему и проверку её актуальности. Ожидаемый результат — понятная точка, после которой продолжение опаснее отката. Если возврат невозможно уложить в окно, миграцию не начинают без пересмотра плана.

V2V: проверки перед сменой гипервизора

V2V — не простое копирование файлов VM. Конвертер или механизм импорта должен преобразовать диск и описание виртуального оборудования под цель: например, VMDK, VHDX или QCOW2 имеют разные возможности и ограничения. Поддерживаемые исходные и целевые форматы, версии форматов и способы импорта проверяют в официальной документации именно целевого гипервизора или конвертера.

  • Исходная цепочка дисков. Убедитесь, что снимки штатно консолидированы, зависимые диски доступны, а у цели достаточно места для результата конвертации. Не перемещайте и не переименовывайте файлы VM в обход поддерживаемой платформой процедуры. О рисках снимков — в статье «Клоны, шаблоны и снимки виртуальных машин».
  • Загрузка. Зафиксируйте BIOS или UEFI, схему разделов, состояние Secure Boot и требования TPM. Целевая VM должна поддерживать выбранный режим; смена поколения VM или режима загрузки без отдельной процедуры может привести к незагрузке.
  • Виртуальные устройства. Сопоставьте типы дисковых контроллеров, сетевых адаптеров, firmware, USB- и PCIe-устройств. Проверьте, что в гостевой ОС есть загрузочный драйвер для целевого контроллера.
  • Драйверы и интеграция. Запланируйте удаление или отключение ненужных гостевых компонентов исходной платформы и установку поддерживаемых компонентов цели: VMware Tools, Hyper-V Integration Services, VirtIO-драйверов или их аналогов. Не удаляйте работающий сетевой или загрузочный драйвер до подтверждения замены.
  • Сеть и приложение. До первого запуска на рабочем сегменте подготовьте новые MAC-адреса, IP-настройки, DNS, правила firewall, зависимые сервисы и лицензии. Приложение может привязывать лицензию к аппаратным признакам или требовать отдельной активации.
  • OVF/OVA. OVF описывает виртуальное устройство, а OVA — его упаковку в один TAR-файл. Импорт OVA в VMware или другую платформу возможен только в пределах поддерживаемых конкретной версией форматов, устройств и параметров; успешный импорт не подтверждает запуск гостевой ОС.

Не запускайте источник и результат V2V в одной рабочей сети без контроля

Две системы с одинаковыми IP-адресом, именем хоста, идентификаторами кластерного узла или прикладными ролями могут нарушить работу сети и данных. Первую загрузку результата выполняют в изолированном сегменте либо с отключённым рабочим сетевым адаптером, пока не проверены идентичность и состояние данных.

P2V: риски переноса с физического сервера

P2V переносит не только файлы, но и установленную ОС с историей физических драйверов и аппаратных зависимостей. VMware Converter не следует считать универсально доступным средством P2V: его доступность, поддерживаемые исходные ОС, целевые версии VMware и ограничения нужно сверять по актуальной официальной документации поставщика перед планированием. То же правило действует для любого другого конвертера.

  • Согласованность данных. Файловая копия работающей системы не всегда согласована для СУБД, очередей, каталогов и других приложений с записью. Нужен поддерживаемый приложением способ остановки, заморозки или финальной синхронизации.
  • Драйверы и загрузка. После P2V гостевая ОС должна загрузиться с виртуального контроллера и обнаружить виртуальные устройства. Режим BIOS/UEFI, схема диска и Secure Boot должны соответствовать возможностям цели.
  • Физические устройства. Привязка к RAID-контроллеру, HBA, GPU, USB-ключу, COM/LPT-порту, специализированной плате или драйверу ядра может не переноситься в VM. Возможность passthrough не означает автоматическую совместимость приложения.
  • Сеть. У перенесённой системы могут сохраниться старые сетевые профили и статические параметры. До рабочего запуска исключите одновременное присутствие физического источника и VM с одной сетевой идентичностью.
  • Лицензии. ОС и прикладное ПО могут учитывать физическое оборудование, тип виртуализации, число ядер или способ активации. Совместимость и порядок переназначения прав подтверждают по правилам поставщиков ОС и приложений.

Минимальный план проверки и отката

Подготовьте контролируемую миграцию

  1. 1
    Инвентаризируйте исходную нагрузку
    Зафиксируйте имя VM или физического сервера, ОС, режим загрузки, диски, контроллеры, сеть, IP/DNS, зависимости приложения, лицензии, объём данных и допустимый простой. Результат — список, по которому можно сопоставить источник и цель. При неизвестной зависимости миграцию откладывают до её проверки.
  2. 2
    Определите критерии успеха и точку отката
    Критерии должны включать запуск ОС, доступность сети, подключение дисков, старт сервисов, проверку данных и одну-две ключевые операции приложения. Заранее назначьте момент принятия решения: например, до включения цели в рабочую сеть или до окончательного переключения клиентов. Если критерии не выполнены к этой точке, возвращаются к исходной системе по согласованному плану.
  3. 3
    Проверьте цель до переключения
    Подтвердите ресурсы хоста, свободное место, поддерживаемость форматов, сеть миграции, сопоставление VLAN и виртуальных коммутаторов, доступность datastore или целевого пути, а также права на функцию. Результат — успешная предварительная проверка платформы или документированный список блокеров. При блокере не заменяйте проверку принудительным запуском операции.
  4. 4
    Выполните первый запуск безопасно
    Для V2V и P2V сначала запускайте результат вне рабочей сети либо с контролируемо отключённой рабочей сетевой связностью. Проверьте загрузку, драйверы, диски и журналы гостевой ОС. При незагрузке вернитесь к подтверждённой конфигурации источника и исправляйте причину на копии, а не на единственном рабочем экземпляре.
  5. 5
    Переключите сервис и подтвердите результат
    Остановите или изолируйте исходную систему в согласованный момент, включите сетевую идентичность цели, выполните контрольные проверки приложения и наблюдайте сервис согласованный период. Исходную и перенесённую системы не возвращают одновременно в рабочую сеть без контроля IP, DNS, имён и актуальности данных.

План отката не является резервным копированием

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

Названия функций, доступность пунктов интерфейса, требования и статусы зависят от модели, поколения, версии firmware, релиза гипервизора, редакции и лицензии. Для конкретной операции используйте официальное руководство выбранного вендора для точной пары исходной и целевой платформ. Подготовка ESXi и vCenter описана в статье об установке VMware vSphere и vCenter Server, а выбор платформы как долгосрочного решения — в сравнении VMware, Hyper-V, Proxmox, KVM и Xen.

Термины в статье

Бессрочная лицензия — право использовать приобретённую версию ПО без фиксированного срока, обычно без автоматического включения обновлений и поддержки.
Технология абстрагирования физических вычислительных ресурсов, позволяющая создавать виртуальные серверы, хранилища, сети и другие логические ресурсы.
Виртуальное оборудование — логическая аппаратная платформа, которую гипервизор предоставляет ВМ: виртуальные процессоры, память, устройства и системную прошивку.
Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Приостановка виртуальной машины (VM stun) — кратковременная внутренняя пауза выполнения ВМ в VMware ESXi для операции с её состоянием или дисками; это не команда Suspend.
Роль Hyper-V — серверная роль Windows Server, устанавливающая гипервизор и компоненты для создания, запуска и управления виртуальными машинами на узле.
Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Холодная миграция — перенос выключенной виртуальной машины между хостами, хранилищами или платформами с переносом её файлов, но без состояния выполнения.
Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
Режим VMware vSphere, задающий общий набор функций CPU для ВМ и обеспечивающий совместимость vMotion между хостами с процессорами разных поколений одного производителя.
Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
HBA — адаптер ввода-вывода, соединяющий сервер с накопителями или SAN и не формирующий аппаратные RAID-массивы.
Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
Hyper-V Integration Services — набор гостевых драйверов и служб для взаимодействия виртуальной машины с гипервизором Microsoft Hyper-V через синтетические устройства.
Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
Перенос работающей виртуальной машины между хостами без выключения гостевой ОС; переключение обычно вызывает краткую паузу, а сохранение соединений зависит от сети и платформы.
Вложенная виртуализация — возможность запускать гипервизор и виртуальные машины второго уровня внутри обычной виртуальной машины.
OVA — однофайловая TAR-упаковка пакета OVF с обязательным OVF-дескриптором, связанными файлами, необязательным манифестом и файлом сертификата при использовании подписи.
OVF — открытый стандарт описания и упаковки виртуального устройства: он задаёт метаданные ВМ и ссылки на её диски, но не является единым архивом.
P2V — перенос установленной ОС, приложений и данных с физического сервера в виртуальную машину с адаптацией системы к виртуальному оборудованию.
Логическая группа портов виртуального коммутатора VMware с общими сетевыми настройками для подключения виртуальных сетевых и VMkernel-адаптеров.
QCOW2 — файловый формат виртуального диска QEMU с выделением места по мере записи, поддержкой backing file, снимков и необязательных функций сжатия или шифрования.
Storage Migration — механизм Hyper-V для переноса файлов работающей виртуальной машины между хранилищами без смены хоста, на котором она выполняется.
Функция VMware vSphere для переноса файлов и виртуальных дисков работающей виртуальной машины между датасторами без её выключения.
V2V — перенос существующей виртуальной машины с одной платформы виртуализации на другую с преобразованием дисков и конфигурации под целевой гипервизор.
Централизованная система управления инфраструктурой VMware для администрирования множества ESXi хостов из единого интерфейса
vGPU — технология предоставления каждой ВМ отдельного виртуального GPU-устройства, позволяющая нескольким ВМ совместно использовать физический ускоритель.
VHDX — формат виртуального диска Microsoft, рассчитанный на Hyper-V и поддерживающий диски до 64 ТБ, журналирование метаданных и современные размеры секторов.
VirtIO — стандарт паравиртуальных устройств для виртуальных машин, заменяющий эмулируемое оборудование интерфейсом, оптимизированным для обмена с гипервизором.
VMDK — формат виртуального диска VMware, в котором данные блочного устройства гостевой ОС хранятся в одном или нескольких файлах.
VMkernel — ядро гипервизора VMware ESXi, которое распределяет ресурсы хоста между ВМ и обрабатывает их сетевой и дисковый ввод-вывод.
Технология VMware vSphere для переноса включённой виртуальной машины между хостами ESXi без выключения гостевой ОС; при переключении возможна краткая пауза.
VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware Converter — средство VMware для преобразования физической или виртуальной системы в виртуальную машину VMware с переносом дисков, конфигурации и данных.
VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
Набор гостевых драйверов и служб VMware, улучшающий интеграцию виртуальной машины с гипервизором и средствами управления.
Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры

Вопросы по теме

Все вопросы и ответы

Что такое vMotion?

vMotion — это название VMware vSphere для переноса включённой виртуальной машины между совместимыми хостами ESXi. Обычно вычислительное состояние VM перемещается на другой хост, а её файлы остаются на datastore, доступном обоим хостам. На финальном переключении VM обычно кратко приостанавливается, поэтому это не безусловная миграция без простоя.

Чем Hyper-V Replica отличается от Live Migration?

Это разные механизмы. Live Migration переносит работающую VM на другой совместимый Hyper-V-хост для планового перемещения нагрузки. Hyper-V Replica не является Live Migration и не заменяется ею: миграция не предназначена для автоматического восстановления после отказа хоста, не создаёт резервную копию и не отменяет необходимость отдельного плана восстановления.

Чем Storage vMotion отличается от vMotion?

vMotion переносит включённую VM между хостами ESXi, обычно без перемещения её файлов с общего datastore. Storage vMotion перемещает файлы и виртуальные диски работающей VM между datastore и не требует обязательной смены хоста. Поэтому для освобождения хранилища может быть достаточно Storage vMotion, а для обслуживания хоста перенос дисков нужен не всегда.

Можно ли считать Live Migration миграцией без простоя?

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

Почему vMotion не работает при наличии двух хостов?

Сначала проверьте, имеют ли оба хоста доступ к совместимому datastore с файлами VM: для обычного vMotion это типовое требование. Затем подтвердите совместимость CPU или корректность EVC, версию виртуального оборудования и отсутствие ограничений со стороны назначенных устройств, vGPU, nested virtualization либо passthrough.

Проверьте связность VMkernel-интерфейсов, выделенных для vMotion, и достаточную пропускную способность сети. Отдельно сопоставьте Port Group, VLAN и внешнюю сеть виртуальной машины на целевом хосте. На цели должны быть свободные CPU и память, а affinity-правила, политики и состояние кластера не должны запрещать размещение.

Также убедитесь, что используемый релиз vSphere, vCenter Server, пакет или действующий entitlement дают право на функцию. Не следует делать вывод по одному признаку, например по наличию ESXi или двух хостов: точную причину определяют по сообщению события и результатам предварительных проверок.

Можно ли импортировать OVA в VMware?

Да, но только если конкретная версия VMware поддерживает формат, устройства и параметры импортируемого образа. OVA — это упаковка виртуального устройства OVF в один TAR-файл. Даже успешный импорт не подтверждает, что гостевая ОС загрузится: нужно проверить режим BIOS/UEFI, Secure Boot, контроллеры, драйверы и сетевую конфигурацию VM.