Миграция виртуальных машин#

Если текущий хост виртуальной машины становится непригодным или больше не может использоваться, или если нужно перераспределить рабочую нагрузку хостинга, можно перенести виртуальную машину на другой хост KVM (Kernel-based Virtual Machine).

Принцип функционирования миграции виртуальных машин#

Важной частью миграции виртуальной машины является копирование ее XML-конфигурации на другой хост. Если перемещаемая виртуальная машина не выключена, миграция также передаст состояние памяти виртуальной машины и любых виртуализированных устройств на целевой хост. Чтобы виртуальная машина оставалась работоспособной на целевом хосте, образы дисков виртуальной машины должны оставаться для нее доступными.

По умолчанию при миграции виртуальная машина переносится на целевой хост и также остается определенной на исходном хосте.

Можно перенести запущенную виртуальную машину используя «живую» миграцию (без остановки виртуальной машины) или миграцию с остановкой виртуальной машины. Чтобы перенести отключенную виртуальную машину, необходимо использовать автономную миграцию.

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

Тип миграции	Описание	Вариант применения	Требования к дисковому хранилищу
Миграция без остановки виртуальной машины(«живая» миграция)	Виртуальная машина продолжает работать на исходном хосте, в то время как KVM передает страницы памяти исходной машины на целевой хост. Когда миграция почти завершена, KVM приостанавливает исходную виртуальную машину и возобновляет ее запуск на целевом хосте	Используется для виртуальных машин, для которых установлено минимальное время отказа. Виртуальные машины, которые изменяют страницы памяти быстрее, чем KVM может их передать, например, такие, как виртуальные машины с большой нагрузкой ввода-вывода, не могут быть перенесены в этом режиме. Для таких виртуальных машин необходимо использовать миграцию с остановкой виртуальной машины	Образы дисков виртуальной машины должны быть расположены в общей сети, доступной как исходному, так и целевому хосту
Миграция с остановкой виртуальной машины(«неживая» миграция)	В процессе миграции виртуальная машина останавливается, на целевой хост копируется ее конфигурация и память, после чего ее работа возобновляется	Рекомендуется для виртуальных машин с большой нагрузкой памяти. В процессе миграции появляется время простоя для виртуальной машины, но данный тип более надежен, чем «живая» миграция	Образы дисков виртуальной машины должны быть расположены в общей сети, доступной как исходному, так и целевому хосту
Автономная миграция(офлайн-миграция)	В процессе миграции конфигурация виртуальной машины перемещается на целевой хост	Рекомендуется для остановленных виртуальных машин и в ситуациях, когда отключение виртуальных машин не нарушает рабочие процессы	Образы дисков виртуальной машины необязательно должны быть доступны в общей сети, вместо этого их можно скопировать или переместить вручную на целевой хост

«Живую» и «неживую» миграции можно комбинировать. Например, при миграции виртуальной машины, которая использует большое количество виртуальных процессоров или существенный объем памяти, завершении миграции может быть затруднено. В этом случае необходимо приостановить исходную виртуальную машину. Это предотвращает выделение дополнительных страниц с занятой памятью и значительно повышает вероятность успешного завершения миграции. Исходя из рабочей нагрузки гостевой системы и количества статических страниц во время миграции, комбинирование типов миграции может привести к значительно меньшему времени простоя, чем миграция с остановкой виртуальной машины.

Преимущества миграции виртуальных машин#

Миграция виртуальных машин может быть полезна для:

балансировки нагрузки – виртуальные машины могут быть перемещены на хост с меньшей загрузкой ресурсов, если текущий хост перегружен, или если другой хост загружен недостаточно;
обеспечения независимости от изменений аппаратной конфигурации – если нужно обновить, добавить или удалить элементы оборудования на хосте, можно безопасно переместить виртуальные машины на другие хосты. Это означает, что виртуальные машины не будут находиться в простое при изменении конфигурации оборудования;
энергосбережения – виртуальные машины могут быть перераспределены на другие хосты. Таким образом, можно высвободить некоторые их хостов и отключить их для экономии энергии и сокращения расходов в периоды низкого использования;
географической миграции – виртуальные машины могут быть перемещены в другое физическое место для уменьшения сетевой задержки или по иным причинам.

Ограничения при миграции виртуальных машин#

Перед миграцией виртуальных машин убедитесь, что миграции не препятствуют следующие ограничения:

Миграция виртуальных машин будет производиться не через сессионное соединение. Миграция посредством libvirt через такое соединение ненадежна, и поэтому использовать ее не следует.
Виртуальные машины, использующие следующие функции и конфигурации, не будут работать правильно после миграции или если миграция завершится неудачей:
- сквозное подключение («проброс») устройств;
- виртуализация ввода-вывода с назначением устройств SR-IOV;
- опосредованные устройства, такие как vGPU (виртуальные графические процессоры).
Миграция между хостами, использующими неоднородный доступ к памяти (NUMA), будет работать только в том случае, если хосты имеют аналогичную топологию. Но и в этом случае миграция может негативно повлиять на производительность выполняемых рабочих нагрузок.
Эмулированные процессоры, как на исходной, так и на целевой виртуальных машинах, должны быть идентичными, в противном случае миграция может завершиться неудачей. Любые различия между виртуальными машинами в перечисленных ниже областях, связанных с процессором, могут вызвать проблемы с миграцией:
- модель процессора:
  - Миграция между хостом Intel 64 и хостом AMD64 не поддерживается, несмотря на то, что они используют общий набор инструкций x86-64.
  - Шаги для обеспечения правильной работы виртуальной машины после миграции на хост с другой моделью процессора см. в разделе «Проверка совместимости ЦП хоста для миграции виртуальной машины».
- установка прошивки;
- версия микрокода;
- версия BIOS;
- настройки BIOS;
- версия QEMU;
- версия ядра.
«Живая» миграция виртуальной машины, которая использует более 1 ТБ памяти, в некоторых случаях может быть ненадежной. Инструкции о том, как предотвратить или устранить эту проблему, см. в разделе «Проблема долгой миграции виртуальной машины без завершения».

Проверка совместимости ЦП хоста для миграции виртуальной машины#

Чтобы перенесенные виртуальные машины правильно работали на целевом хосте, процессоры на исходном и целевом хостах должны быть совместимы. Поэтому рекомендуется рассчитать общий базовый уровень ЦП (центрального процессора), прежде чем начинать миграцию.

Перед проверкой совместимости убедитесь, что:

в системе установлена, настроена и запущена виртуализация;
администратор имеет доступ к исходному и целевому хостам для миграции.

Для проверки совместимости ЦП хоста для миграции выполните следующие шаги:

На исходном хосте получите свойства его процессора и вставьте их в новый XML-файл:
```
virsh domcapabilities | xmllint --xpath "//cpu/mode[@name='host-model']" - > <filename>.xml
```

В XML-файле замените теги <mode> </mode> на <cpu> </cpu>.

Пример скорректированного содержимого файла <filename>.xml представлен ниже:

<cpu>
      <model fallback="forbid">Skylake-Client-IBRS</model>
      <vendor>vendor-name</vendor>
      <feature policy="require" name="ss"/>
      <feature policy="require" name="vmx"/>
      <feature policy="require" name="pdcm"/>
      <feature policy="require" name="hypervisor"/>
      <feature policy="require" name="tsc_adjust"/>
      <feature policy="require" name="clflushopt"/>
      <feature policy="require" name="umip"/>
      <feature policy="require" name="md-clear"/>
      <feature policy="require" name="stibp"/>
      <feature policy="require" name="arch-capabilities"/>
      <feature policy="require" name="ssbd"/>
      <feature policy="require" name="xsaves"/>
      <feature policy="require" name="pdpe1gb"/>
      <feature policy="require" name="invtsc"/>
      <feature policy="require" name="ibpb"/>
      <feature policy="require" name="ibrs"/>
      <feature policy="require" name="amd-stibp"/>
      <feature policy="require" name="amd-ssbd"/>
      <feature policy="require" name="rsba"/>
      <feature policy="require" name="skip-l1dfl-vmentry"/>
      <feature policy="require" name="pschange-mc-no"/>
      <feature policy="disable" name="hle"/>
      <feature policy="disable" name="rtm"/>
</cpu>

На целевом хосте используйте следующую команду, чтобы получить список свойств процессора:

virsh domcapabilities | xmllint --xpath "//cpu/mode[@name='host-model']" -

Вывод команды:

<mode name="host-model" supported="yes">
      <model fallback="forbid">IvyBridge-IBRS</model>
      <vendor>vendor-name</vendor>
      <feature policy="require" name="ss"/>
      <feature policy="require" name="vmx"/>
      <feature policy="require" name="pdcm"/>
      <feature policy="require" name="pcid"/>
      <feature policy="require" name="hypervisor"/>
      <feature policy="require" name="arat"/>
      <feature policy="require" name="tsc_adjust"/>
      <feature policy="require" name="umip"/>
      <feature policy="require" name="md-clear"/>
      <feature policy="require" name="stibp"/>
      <feature policy="require" name="arch-capabilities"/>
      <feature policy="require" name="ssbd"/>
      <feature policy="require" name="xsaveopt"/>
      <feature policy="require" name="pdpe1gb"/>
      <feature policy="require" name="invtsc"/>
      <feature policy="require" name="ibpb"/>
      <feature policy="require" name="amd-ssbd"/>
      <feature policy="require" name="skip-l1dfl-vmentry"/>
      <feature policy="require" name="pschange-mc-no"/>
</mode>

Добавьте полученное описание ЦП целевого хоста в файл <filename>.xml на исходном хосте. Замените теги <mode> </mode> на <cpu> </cpu>, и сохраните файл.

XML-файл должен содержать описание свойств ЦП обоих хостов.

Пример файла:

<cpu>
      <model fallback="forbid">Skylake-Client-IBRS</model>
      <vendor>vendor-name</vendor>
      <feature policy="require" name="ss"/>
      <feature policy="require" name="vmx"/>
      <feature policy="require" name="pdcm"/>
      <feature policy="require" name="hypervisor"/>
      <feature policy="require" name="tsc_adjust"/>
      <feature policy="require" name="clflushopt"/>
      <feature policy="require" name="umip"/>
      <feature policy="require" name="md-clear"/>
      <feature policy="require" name="stibp"/>
      <feature policy="require" name="arch-capabilities"/>
      <feature policy="require" name="ssbd"/>
      <feature policy="require" name="xsaves"/>
      <feature policy="require" name="pdpe1gb"/>
      <feature policy="require" name="invtsc"/>
      <feature policy="require" name="ibpb"/>
      <feature policy="require" name="ibrs"/>
      <feature policy="require" name="amd-stibp"/>
      <feature policy="require" name="amd-ssbd"/>
      <feature policy="require" name="rsba"/>
      <feature policy="require" name="skip-l1dfl-vmentry"/>
      <feature policy="require" name="pschange-mc-no"/>
      <feature policy="disable" name="hle"/>
      <feature policy="disable" name="rtm"/>
</cpu>
<cpu>
      <model fallback="forbid">IvyBridge-IBRS</model>
      <vendor>vendor-name</vendor>
      <feature policy="require" name="ss"/>
      <feature policy="require" name="vmx"/>
      <feature policy="require" name="pdcm"/>
      <feature policy="require" name="pcid"/>
      <feature policy="require" name="hypervisor"/>
      <feature policy="require" name="arat"/>
      <feature policy="require" name="tsc_adjust"/>
      <feature policy="require" name="umip"/>
      <feature policy="require" name="md-clear"/>
      <feature policy="require" name="stibp"/>
      <feature policy="require" name="arch-capabilities"/>
      <feature policy="require" name="ssbd"/>
      <feature policy="require" name="xsaveopt"/>
      <feature policy="require" name="pdpe1gb"/>
      <feature policy="require" name="invtsc"/>
      <feature policy="require" name="ibpb"/>
      <feature policy="require" name="amd-ssbd"/>
      <feature policy="require" name="skip-l1dfl-vmentry"/>
      <feature policy="require" name="pschange-mc-no"/>
</cpu>

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

virsh hypervisor-cpu-baseline <filename>.xml

Вывод команды:

    <cpu mode='custom' match='exact'>
      <model fallback='forbid'>IvyBridge-IBRS</model>
      <vendor>vendor-name</vendor>
      <feature policy='require' name='ss'/>
      <feature policy='require' name='vmx'/>
      <feature policy='require' name='pdcm'/>
      <feature policy='require' name='pcid'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='arat'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='umip'/>
      <feature policy='require' name='md-clear'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='xsaveopt'/>
      <feature policy='require' name='pdpe1gb'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='ibpb'/>
      <feature policy='require' name='amd-ssbd'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='require' name='pschange-mc-no'/>
    </cpu>

Откройте XML-конфигурацию виртуальной машины, которую необходимо мигрировать, и замените содержимое секции <cpu> описанием, полученным на предыдущем шаге:
```
virsh edit <vm-name>
```
Если виртуальная машина запущена, перезапустите ее:
```
virsh reboot <vm-name>
```

Совместное использование образов дисков виртуальной машины с другими хостами#

Для выполнения «живой» миграции виртуальной машины между поддерживаемыми KVM-хостами требуется общее хранилище виртуальных машин. Настроить совместное использование локально сохраненного образа ВМ исходным хостом и целевым хостом можно с применением протокола NFS.

Перед настройкой совместного хранилища убедитесь, что:

виртуальная машина, предназначенная для миграции, остановлена;
хост, доступный для размещения хранилища, которое не является исходным или целевым хостом, но исходный и целевой хосты могут получить к нему доступ через сеть;
не используется блокировка файлов NFS (данная функциональность не поддерживается в KVM).
NFS установлена и включается на исходном и целевом хостах.

Примечание

Если NFS не установлена:

Установите пакет NFS:
```
dnf install nfs-utils
```

Убедитесь, что порты для NFS, такие, как 2049, открыты в брандмауэре:

firewall-cmd --permanent --add-service=nfs
firewall-cmd --permanent --add-service=mountd
firewall-cmd --permanent --add-service=rpc-bind
firewall-cmd --permanent --add-port=2049/tcp
firewall-cmd --permanent --add-port=2049/udp
firewall-cmd --reload

Запустите службу NFS:
```
systemctl start nfs-server
```

Для настройки совместного хранилища выполните следующий сценарий:

Подключитесь к хосту, который предоставляет общее хранилище:
```
ssh root@<shared-storage-host>
```
Где <shared-storage-host> - адрес хоста общего хранилища.
Создайте каталог, который будет хранить образ диска и будет совместно использоваться хостами миграции:
```
mkdir /var/lib/libvirt/<shared-images>
```
Где <shared-images> – имя каталога.
Скопируйте образ диска виртуальной машины с исходного хоста в каталог, созданный на предыдущем шаге:
```
scp /var/lib/libvirt/images/<example-disk-1>.qcow2 root@<shared-storage-host>:/var/lib/libvirt/<shared-images>/<example-disk-1>.qcow2
```
Где <example-disk-1> - образ диска ВМ.
Добавьте каталог <shared-images> в файл /etc/exports. В следующем примере каталог /var/lib/libvirt/shared-images используется совместно хостами example-source-machine и example-destination-machine:
```
/var/lib/libvirt/<shared-images> example-source-machine(rw,no_root_squash) example-destination-machine(rw,no\_root_squash)
```
На исходном и целевом хостах смонтируйте общий каталог в каталоге /var/lib/libvirt/images:
```
mount <shared-storage-host>:/var/lib/libvirt/<shared-images> /var/lib/libvirt/images
```

Для проверки запустите виртуальную машину на исходном хосте и посмотрите, успешно ли она загружается.

Миграция виртуальной машины с помощью интерфейса командной строки#

Если текущий хост ВМ становится непригодным или больше не может использоваться, или если необходимо перераспределить рабочую нагрузку хостинга, существует возможность перенести ВМ на другой хост KVM. Инструкции и примеры для различных сценариев таких миграций приведены ниже.

Перед миграцией ВМ убедитесь, что:

исходный и целевой хост используют гипервизор KVM.
исходный хост и целевой хост могут связаться друг с другом по сети.

Примечание

Для проверки соединения используйте утилиту ping.
на целевом хосте открыты следующие порты:
- 22 – необходим для подключения к целевому хосту с помощью SSH;
- 16509 – необходим для подключения к целевому хосту с помощью TLS;
- 16514 – необходим для подключения к целевому хосту с помощью TCP;
- 49152-49215 – необходимы QEMU для передачи данных при переносе памяти и диска.
исходный хост и целевой хост используют конкретные операционные системы и типы машин.
виртуальная машина совместима с функциями процессора целевого хоста.

Примечание

Подробнее см. раздел «Проверка совместимости ЦП хоста для миграции виртуальной машины».
образы дисков ВМ, которые будут участвовать в миграции, расположены на хосте, доступном как исходному и целевому хостам. Требуется для «живой» миграции ВМ.

Примечание

Подробнее см. раздел «Совместное использование образов дисков виртуальной машины с другими хостами».
при «живой» миграции пропускная способность используемой сети должна быть выше скорости, с которой ВМ генерирует «грязные страницы» памяти.

Примечание

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

Чтобы узнать скорость возникновения «грязных страниц» виртуальной машины перед началом «живой» миграции, выполните следующие действия:
- Отследите скорость генерации «грязных страниц» виртуальной машины в течение короткого периода времени, например, 30 секунд:
```
virsh domdirtyrate-calc <example-vm> --seconds 30
```
- После завершения мониторинга получите его результаты:
```
virsh domstats <example-vm> --dirtyrate
```
Возможный вывод результатов для периода 30 секунд:
```
Domain: '<example-vm>'
  dirtyrate.calc_status=2
  dirtyrate.calc_start_time=200942
  dirtyrate.calc_period=30
  dirtyrate.megabytes_per_second=2
```
В примере ВМ генерирует 2 МБ «грязных страниц» памяти в секунду. Попытка миграции такой ВМ в сети с пропускной способностью 2 МБ/с или менее приведет к тому, что «живая» миграция не сможет завершиться, если не приостановить виртуальную машину или не снизить ее рабочую нагрузку. Чтобы обеспечить успешное завершение «живой» миграции, нужно чтобы пропускная способность сети была значительно больше, чем скорость генерации «грязных страниц» ВМ.
при миграции ВМ через общедоступную сеть исходный и целевой хосты должны располагаться в одной сети. Иначе сеть ВМ не будет работать после миграции.
при выполнении миграции ВМ virsh на исходном хосте может использовать один из нескольких протоколов для подключения к демону libvirt на целевом хосте:
- Для использования SSH-соединения убедитесь, что сокет virtqemud включен и работает на целевом хосте:
```
systemctl enable --now virtqemud.socket
```
- Для использования TLS-соединения убедитесь, что сокет virtproxyd-tls включен и работает на целевом хосте:
```
systemctl enable --now virtproxyd-tls.socket
```
- Для использования TCP-соединения убедитесь, что сокет virtproxyd-tcp включен и работает на целевом хосте:
```
systemctl enable --now virtproxyd-tcp.socket
```

Примечание

В сценарии ниже используется SSH-соединение.

Для миграции ВМ выполните следующие шаги:

Используйте команду virsh migrate, чтобы перенести ВМ с исходного на целевой хост. Примеры применения virsh migrate для различных задач миграции приведены ниже:
- Для «живой» миграции ВМ <example-vm> с локального хоста на целевой хост <destination-host> с помощью SSH-соединения используйте команду virsh migrate со следующими опциями:
```
virsh migrate --persistent --live <example-vm> qemu+ssh://<destination-host>/system
```
- Для изменения конфигурации запущенной ВМ <example-vm> вручную и последующей миграции ВМ с локального хоста на целевой хост <destination-host> используйте следующую последовательность команд:
  
  Примечание
  
  Перенесенная ВМ автоматически будет использовать конфигурацию, обновленную на локальном хосте.
  
  Получите конфигурацию ВМ и перенаправьте вывод в файл:
```
virsh dumpxml --migratable <example-vm> > <example-vm>.xml
```
  Измените конфигурацию в соответствии с требованиями:
```
vi <example-vm>.xml
```
  Перенесите ВМ вместе с измененной конфигурацией:
```
virsh migrate --live --persistent --xml <example-vm>.xml <example-vm> qemu+ssh://<destination-host>/system
```
  Данный пример может быть полезен, например, когда хосту назначения необходимо использовать другой путь для доступа к общему хранилищу ВМ или при настройке функции, специфичной для целевого хоста.
- Для миграции приостановленной ВМ с исходного хоста <source-host> на целевой хост <destination-host> и дополнительным предписанием целевому хосту использовать скорректированную конфигурацию XML, предоставленную файлом <example-vm>.xml используйте команду virsh migrate со следующим набором опций:
```
virsh migrate <example-vm> qemu+ssh://<source-host>/system qemu+ssh://<destination-host>/system --xml <example-vm>.xml
```
  После завершения миграции ВМ находится в состоянии отключения на исходном хосте, и перенесенная копия удаляется после ее завершения. На целевом хосте после миграции libvirt возобновляет работу ВМ.
- Для удаления остановленной ВМ с исходного хоста <source-host> и переноса ее конфигурации на целевой хост <destination-host> используйте команду:
```
virsh migrate --offline --persistent --undefinesource <example-vm> qemu+ssh://<source-host>/system qemu+ssh://<destination-host>/system
```
  В этом примере для миграции не требуется перемещения образа диска ВМ в общее хранилище. Но, чтобы ВМ можно было использовать на целевом хосте, необходимо перенести образ диска ВМ. Например, с помощью команды:
```
scp root@<source-host>:/var/lib/libvirt/images/<example-vm>.qcow2 root@<destination-host>:/var/lib/libvirt/images/<example-vm>.qcow2
```
Дождитесь завершения миграции. Процесс может занять некоторое время в зависимости от пропускной способности сети, нагрузки системы и размера ВМ. Если опция --verbose утилиты virsh не используется с командой миграции, интерфейс командной строки не отображает никаких индикаторов прогресса, кроме ошибок.

Примечание

Если процесс миграции уже запущен, для отображения статистики используйте команду virsh domjobinfo.

Для того чтобы проверить, была ли перенесена ВМ на целевой хост, просмотрите на нем список доступных ВМ с помощью команды:

virsh list

Возможный вывод команды:

Id      Name             State
----------------------------------
10    <example-vm>      running

Если миграция все еще продолжается, команда покажет состояние ВМ как paused.

Устранение неисправностей#

В некоторых случаях целевой хост может быть несовместим с определенными значениями XML-конфигурации перенесенной ВМ, такими как имя сети или тип процессора. В результате перенесенная ВМ может не загрузиться. Чтобы устранить эти проблемы, нужно обновить проблемные значения с помощью команды virsh edit. После обновления значений перезапустите ВМ для применения изменений.

Продолжительная «живая» миграция может быть связана с тем, что ВМ находится под большой нагрузкой. Большое количество страниц памяти меняется и не дает завершиться миграции. Чтобы решить эту проблему, используйте миграцию с остановкой виртуальной машины вместо «живой» миграции, приостановив виртуальную машину командой virsh suspend <example-vm>.

Дополнительную информацию можно получить, выполнив команды virsh migrate --help и man virsh.

Проблема долгой миграции виртуальной машины без завершения#

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

Частые причины:

«Живая» миграция ВМ с большой нагрузкой.
«Живая» миграция ВМ, которая использует большой объем памяти, например, 1 ТБ или более.

Определение проблемы#

Если миграция ВМ занимает больше времени, чем ожидалось, используйте команду virsh domjobinfo, чтобы получить информацию о страницах памяти ВМ:

virsh domjobinfo <vm-name>

Возможный вывод команды:

Job type:         Unbounded
Operation:        Outgoing migration
Time elapsed:     168286974    ms
Data processed:   26.106 TiB
Data remaining:   34.383 MiB
Data total:       10.586 TiB
Memory processed: 26.106 TiB
Memory remaining: 34.383 MiB
Memory total:     10.586 TiB
Memory bandwidth: 29.056 MiB/s
Dirty rate: 17225 pages/s
Page size: 4096 bytes

В примере вывода выше видно, что произведение значений Dirty rate и Page size намного больше значения Memory bandwidth. Это означает, что ВМ генерирует «грязные страницы» памяти быстрее, чем их можно передать через сеть. Состояние ВМ на целевом хосте не совпадает с состоянием ВМ на исходном хосте, что не позволяет завершиться миграции.

Решение#

Для решения проблемы с затянувшейся «живой» миграцией, воспользуйтесь следующими вариантами:

Уменьшите нагрузку на ВМ, приводящую к выделению памяти. Для этого остановите или отмените несущественные процессы в гостевой ОС исходной ВМ.
Увеличьте время простоя, допустимое при «живой» миграции. Для этого:
1. Выведите текущее максимальное время простоя до завершения «живой» миграции ВМ:
```
virsh migrate-getmaxdowntime <vm-name>
```
2. Установите максимальное время простоя до завершения миграции:
```
virsh migrate-setmaxdowntime <vm-name> downtime-in-miliseconds
```
  Примечание
  
  Чем выше максимальное время простоя, тем больше вероятность того, что миграция будет завершена.
Переключите живую миграцию в режим post-copy.
```
virsh migrate-start-postcopy <vm-name>
```
В этом случае страницы памяти ВМ совпадут на целевом хосте, и миграция может завершиться.

Примечание

Когда активирован режим post-copy, ВМ может значительно замедлиться из-за наличия удаленных запросов страниц памяти от целевого хоста к исходному. Кроме того, если сетевое соединение между исходным и целевым хостами перестанет работать во время миграции post-copy, некоторые процессы ВМы могут остановиться из-за отсутствия доступа к страницам памяти.

Не используйте post-copy миграцию, если доступность ВМ критична или нестабильно сетевое соединение.
Если рабочая нагрузка позволяет, приостановите ВМ и позвольте миграции завершиться как в случае с миграцией остановленной ВМ. Это увеличит время простоя ВМ, но гарантирует успешное завершение миграции.