Windows Hyper-V with it's live migration is a great feature… when it works! Unfortunately after setting it up things weren't quite working as expected. During move following error was given:
The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: no suitable credentials available. Make sure the operation is initiated on the source host of the migration, or the source host is configured to use Kerberos for the authentication of migration connections and Constrained Delegation is enabled for the host in Active Directory.
[Expanded Information]
Virtual machine migration operation for … failed at migration source ‘ServerA'. (Virtual machine ID)
The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘ServerB': No credentials are available in the security package (0x8009030E).
Failed to authenticate the connection at the source host: no suitable credentials available.
Following message appears during VM move:
While there are multiple steps one has to do before Live Migration works in this case most of the settings where already at their correct values:
Enable incoming and outgoing live migrations
Use Kerberos
Trust this computer for delegation to any service (Kerberos only)
And things still didn't work!
While Trust this computer for delegation to any service (Kerberos only) seems like a best option to test things out if Live migration works, actually it's not. After setting up direct delegation for Trust this computer for delegation to specified services only and choosing
CIFS
Microsoft Virtual System Migration Service
Seems to fix the issue…
Of course after setting this up please wait up to 15 minutes for Keberos tickets to timeout or run
KLIST PURGE -li 0x3e7
If you want to be safe for the Windows 2012 R2 to Windows 2016 make sure to use Use any authentication protocol as things has changed between Winodws Server versions.
The reason for this is that Windows Server 2016 has changed the WMI provider used to a new version, which relies on WinRM to execute remote procedures rather than DCOM. WinRM, running as the Network Service, cannot access the Kerberos service ticket obtained to perform the action.