Three Hyper-V Issues that Prevent Successful Hyper-V Live Migration

Aside from the standard “make sure you are working with domain joined computers,” I have run across three different issues that can prevent Hyper-V online live migrations from succeeding.

The first is the Live Migrations settings themselves.  These must be set correctly for both the source and destination server.  In Hyper-V Manager, right-click the server and select “Hyper-V Settings.”  Make sure that you have enabled incoming and outgoing live migrations, you have allowed as many simultaneous live migrations as you plan on doing at once, and if you have set only specific IP addresses for live migration, that you set them on both the source and destination Hyper-V servers.

 

Next is Kerberos.  This one classifies as a security feature.  By default, you cannot delegate permissions across two servers.  You need to enable Kerberos delegation in order to pass your credentials through to the remote Hyper-V server.  If it is not setup, you can receive one of a few different access denied errors.  Here is one example:

 

You fix this issue by turning on Kerberos delegation in Active Directory.  In this example, Kerberos delegation (cifs) for the source HV02 server has been enabled to trust the destination Hyper-V host HV01 and the two Hyper-V guests DEV and mt2 that will be moved from HV02 to HV01.  In addition,  Microsoft Virtual Console Service and Microsoft Virtual System Migration Service have both been enabled for the destination Hyper-V host HV01.

The HV01 computer object in Active Directory has been set with identical Kerberos delegation settings.  Just swap HV02 and HV01 in the example.

 

The third is a bug I’ve run across when performing live migrations.  It can occur when you have teamed NICs.  You get a not so nice error saying your computer “Actively Refused” to move the Hyper-V for you.

No connection could be made because the target machine actively refused it. 

I do not know about you, but I get offended when my computer actively refuses to do something I want it to do.  Assuming you have all your settings correct on the first issue above, this can be caused by this service trying to initialize before the team is ready.  You can tell if this is your issue or not by checking to see if your teamed NIC is listening on port 6600.  Run netstat-a and look for both TCP and UDP for the IP of your team listening on port 6600.

 

The entry in the screenshot above shows what you should see: your server listening on port 6600.  With this missing, your Hyper-V move will fail and it will actively refuse your request.

The fix is simple.  You can do this will all your Hyper-V machines up and running.  Restart the Hyper-V Virtual Machine Management service on the server that is not listening on the port.  Verify it is now listening using your netstat -a command.  Check both TCP and scroll down to verify UDP is also listening on port 6600.  Your Hyper-V move should succeed now.