Технологія 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: \ hyperv \ vm
У тому випадку, якщо в настройках ВМ не включений режим сумісності процесорів, міграція перерветься з помилкою:
The virtual machine can not 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