Технология Live Migration в системе виртуализации Hyper-V позволяет перемещать запущенную виртуальную машину между хостами Hyper-V без прерывания ее работы и доступности сервисов. В ранних версиях Hyper-V виртуальную машину возможно было переместить с помощью Live Migration только между узлами кластера (Failover Cluster). В Hyper-V 3.0 (Windows Server 2012) и выше этого ограничения больше нет благодаря технологии Shared Nothing Live Migration . В этой статье мы покажем, как включить Live Migration и перенести запущенную ВМ между отдельно стоящими серверами Hyper-V на базе Windows Server 2016.
Требования, необходимые для выполнения Shared Nothing Live Migration:
- Перемещение возможно между серверами со следующими версиями ОС: Windows Server 2012 R2 или Windows Server 2016
- Версия виртуальной машины должна быть не ниже 5
- Оба компьютера должны состоять в одном домене Active Directory, либо в доменах с двустороннем доверием
- У пользователя выполняющего настройки должны быть права администратора Hyper-V. При настройке ограниченного делегирования Kerberos пользователь должен обладать правами администратора домена (либо ему должны быть предоставлены права на учетные записи серверов в AD)
Допустим у нас имеется 2 сервера с Windows Server 2016 с установленной ролью HyperV: Srv01 и Srv03. Оба сервера включены в домен Active Directory и не объединены в кластер WSFC (Windows Server Failover Clustering). Запустим на любом из серверов консоль Hyper-V Manager и добавим в нее оба сервера.
Далее в настройках обоих серверов Hyper–V нужно разрешить Live Migration. Для этого ПКМ по серверу Hyper-V и выберите пункт Hyper — V Settings . Перейдите в раздел Live Migration и включите опцию Enable incoming and outgoing live migrations . Ограничим список миграций IP адресами двух хостов Hyper-V.
Затем в разделе настроек Advanced Features выберите протокол аутентификации Kerberos (Use Kerberos).
Рассмотренные выше действия можно выполнить с помощью таких команд PowerShell:
Enable-VMMigration
Set-VMMigrationNetwork 192.168.10.41 192.168.10.21
Set-VMHost -VirtualMachineMigrationAuthenticationType
Примечание . Возможна живая миграция ВМ и с помощью протокола CredSSP, но в этом случае администратору потребуется выполнить локальный вход (по RDP) на сервер-источник миграции или подключиться удаленно через PowerShell Remoting .
Для осуществления миграции ВМ с помощью аутентификации Kerberos администратору не нужно логиниться на сервере, но требуется настройка ограниченного делегирования в Active Directory (KCD — Kerberos constrained delegation)
Запустите оснастку ADUC , найдите учетную запись первого сервера Hyper-V, откройте его свойства и перейдите на вкладку Delegation (Делегирование).
Выберите опции: Trust this computer for delegation to specified services only и Use Kerberos only и нажмите на кнопку Add .
В следующем окне нажмите на кнопку Users and Computers и укажите имя второго сервера Hyper V. В списке доступных служб выберите M icrosoft Virtual System Migration Service .
Совет . Если нужно также выполнять миграцию хранилища ВМ, нужно также выбрать протокол cifs
Сохраните настройки делегации. Аналогичные настройки проведите с учетной записью второго сервера Hyper-V.
Осталось дождаться репликации изменений в AD, и перевыпуска билета Kerboros и можно попытаться выполнить живую миграцию ВМ. Щелкните ПКМ по виртуальной машине и выберите Move . 
В качестве типа миграции выберите Move the virtual machine .
Укажите имя хоста Hyper-V, на который нужно выполнить перенос.
Затем укажите каталог на целевом хосте, в который нужно поместить файлы ВМ (каталог должен существовать).
Нажмите кнопку Finish и дождитесь окончания процесса Live Migration виртуальной машина на второй сервер Hyper-V.
Совет . Миграцию ВМ можно запустить с помощью такой PowerShell команды:
Move-VM srvapp1 Srv01 -IncludeStorage -DestinationStoragePath c:hypervvm
В том случае, если в настройках ВМ не включен режим совместимости процессоров, миграция прервется с ошибкой:
The virtual machine cannot be moved to the destination computer. The hardware on the destination computer is not compatible with the hardware requirements of this virtual machine.
Для решения проблемы придется выключить ВМ и включить для нее режим совместимости CPU:
Set-VMProcessor srvapp1 -CompatibilityForMigrationEnabled $true
