Живая миграция переносит работающую виртуальную машину на другой физический хост без заметной для пользователя остановки. Документ VMware описывает предварительное итеративное копирование памяти: каждый следующий проход передаёт только страницы, изменившиеся после предыдущей итерации.
В статье — официальная механика VMware vMotion и Microsoft Hyper-V Live Migration: как копируется память работающей машины, что происходит в момент финального переключения, какие есть официальные требования к общему хранилищу и сети, и что вендоры официально говорят о поведении при нехватке пропускной способности. Про требования к платформе виртуализации при построении кластера — в статье «Минимальный отказоустойчивый кластер — что реально нужно».
Что разобрано в статье
Предварительное копирование
Официальный механизм VMware: итеративное копирование изменяющейся памяти работающей ВМ.
Финальное переключение
Официальная инженерная цель VMware — переключение короче одной секунды.
Общее хранилище
Официальные требования и официальный сценарий миграции без него.
Hyper-V
Официальный шестишаговый процесс живой миграции и режим без общих ресурсов.
Нехватка сети
Официальный тайм-аут VMware (100/135 секунд) и поведение при отказе.
Как vMotion копирует память: pre-copy по шагам
Документ VMware о vMotion в VMware vSphere 7.0 U1 описывает процесс тремя фазами. Сначала система помечает страницы гостевой памяти, чтобы отслеживать изменения во время миграции. Затем память итеративно копируется с исходного хоста ESXi на целевой: на каждом проходе передаются только страницы, изменившиеся после предыдущей итерации.
Технически отслеживание реализовано через таблицы страниц виртуальной машины. Для контролируемых записей выставляется признак «только чтение»; попытка гостевой системы изменить такую страницу вызывает исключение страницы, которое обрабатывает монитор виртуальной машины и передаёт vMotion сигнал об изменении. Виртуальная машина продолжает работать на исходном хосте, а система фиксирует, какие страницы успели измениться после прошлого прохода.
Финальное переключение: почему оно почти незаметно
VMware определяет время финального переключения как интервал, необходимый для приостановки виртуальной машины на исходном хосте, создания контрольной точки устройств, передачи её вместе с оставшимися изменёнными страницами, восстановления состояния и запуска гостевой системы на целевом хосте. Инженерная цель vMotion — удерживать этот интервал короче одной секунды. Это цель разработки, а не гарантированный SLA для любой конфигурации.
На финальной фазе виртуальная машина кратковременно приостанавливается на исходном хосте ESXi, последние изменения памяти копируются на целевой хост, после чего машина возобновляет работу там. Простой существует, но охватывает передачу небольшого остатка изменившихся страниц, а не полное копирование состояния.
Официальные требования к сети vMotion
VMware требует не менее 250 Мбит/с выделенной полосы на каждую одновременную сессию vMotion. Максимально поддерживаемое время прохождения сигнала туда и обратно для миграции на большие расстояния — 150 мс. Сеть vMotion должна быть защищённой и доступной только доверенным сторонам.
Как это устроено у Hyper-V Live Migration
Microsoft описывает процесс из шести стадий. Предварительное копирование памяти на целевой сервер сокращает время окончательного переноса. Hyper-V выполняет несколько итераций, и на каждом следующем проходе требуется передать меньше изменённых страниц. До завершения этого этапа миграцию можно отменить без последствий для исходной машины.
Microsoft даёт только качественный ответ о длительности простоя: живая миграция завершается быстрее тайм-аута TCP для переносимой виртуальной машины, а сам интервал зависит от топологии сети и других факторов. Конкретного числа в секундах в источнике нет; этот пробел честно зафиксирован в sources.md.
Что происходит при нехватке пропускной способности
База знаний Broadcom поясняет: если исходный хост не успевает передать контрольную точку и страницы памяти за стандартные 100 секунд из-за пропускной способности или задержки сети, ESX заранее прекращает миграцию, чтобы виртуальная машина продолжила работать на исходном хосте. Параметр vmotion.maxSwitchoverSeconds можно увеличить, но не более чем до 135 секунд. При нехватке сети миграция не зависает бесконечно, а прекращается с сохранением работающей исходной машины.
Честная оговорка: у Microsoft для Hyper-V Live Migration официального аналога с конкретным числом тайм-аута найти не удалось — только качественная привязка к тайм-ауту TCP-соединения, без указанного вендором конкретного значения в секундах.
Частые вопросы
Правда ли, что во время живой миграции виртуальная машина вообще не останавливается?
Официально — почти. Официальная документация обоих вендоров описывает короткую финальную фазу, когда машина действительно кратковременно приостанавливается для передачи последних изменений. VMware официально называет инженерную цель для этой паузы — «под одну секунду»; Microsoft даёт лишь качественное описание — короче тайм-аута TCP-соединения, без конкретной цифры.
Обязательно ли общее хранилище для живой миграции?
Нет, у обоих вендоров официально задокументирован сценарий без общего хранилища: у VMware это отдельный режим vMotion без общего хранилища, у Microsoft — живая миграция без общих ресурсов. В обоих случаях содержимое диска дополнительно передаётся по сети, что увеличивает время и требования к пропускной способности по сравнению со сценарием с общим хранилищем.
Нужен ли отказоустойчивый кластер для живой миграции Hyper-V?
По официальной документации Microsoft — уже нет, начиная с Windows Server 2016. Живая миграция официально работает и без отказоустойчивого кластера, между двумя обычными серверами Hyper-V в одном домене Active Directory или в доверяющих друг другу доменах.
Что произойдёт, если во время миграции не хватит пропускной способности сети?
По официальной документации VMware — миграция гарантированно отменяется по тайм-ауту (по умолчанию 100 секунд, настраиваемый максимум 135), и виртуальная машина продолжает работать на исходном хосте без последствий. У Microsoft официального аналога с конкретной цифрой тайм-аута не найдено — только качественная привязка к TCP-таймауту.
Обсуждают ли вендоры миграцию с копированием памяти после переключения?
Честно: в официальной документации ни VMware, ни Microsoft упоминания такого метода как реализованной или поддерживаемой технологии не найдено. Оба вендора используют предварительное итеративное копирование памяти во время работы машины.
Поможете спроектировать инфраструктуру под живую миграцию виртуальных машин?
Да. Пришлите требования к отказоустойчивости и параметры сети между хостами на info@andpro.ru или через форму на /services/ — подберём серверы и сетевую конфигурацию под задачу.
Авторство и ответственность
Материал подготовлен для блога ANDPRO / ООО «АНД-Системс» как информационная статья о механике живой миграции виртуальных машин. Статья не заменяет индивидуальное проектирование конфигурации виртуализации под конкретную инфраструктуру и требования к отказоустойчивости.
Материал подготовлен при участии AI-ассистента, прошёл фактчекинг и редакторскую вычитку. Формулировки проверены против официальной документации VMware/Broadcom и Microsoft — см. sources.md.
Для подбора инфраструктуры виртуализации обратитесь в ANDPRO: info@andpro.ru, +7 (495) 545-48-70, +7 (800) 707-78-15.
Дата последнего обновления материала: 6 сентября 2026 года.
