If you would like to read the other parts in this article series please go to:
Introduction
As I have explained throughout this article series, there are a number of different conditions that can result in a Hyper-V live migration failure.
In this article, I want to revisit a previously discussed error message because there is another cause of the error.
Failed to Establish a Connection with the Host
The particular error message that I want to revisit is the Failed to Establish a Connection With the Host message. The exact error message is:
Virtual machine migration operation failed at migration source.
Failed to establish a connection with host. No credentials are available in the security package (0x8009030E).
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.
You can see the actual error message in Figure A.
Figure A: This is one of the most common Hyper-V live migration error messages.
As I explained in the previous article, this particular error message is often the result of a security problem. Typically, CredSSP is being used for authentication and the live migration operation was initiated on a server other than the one that is presently hosting the virtual machine. As previously explained, the best way to correct this particular problem is to enable Kerberos authentication and to configure constrained delegation.
As it turns out however, this particular error can occur even if Kerberos is enabled and is correctly configured. The problem can occur as a result of logging in to an incorrect domain. Let me explain.
Last week, I spent a considerable amount of time working on a Hyper-V book that I am writing. Because I don’t want to make configuration changes to production systems, I set up a management domain called MGMT.com. The MGMT.com domain exists at the host server level. Its job is to group all of the Hyper-V hosts into a common domain for easier manageability.
In addition to the MGMT.com domain, I also created a number of different lab domains that exist at the virtual machine level. These lab domains allow me to experiment with various techniques that I am writing about, but without jeopardizing the MGMT.com forest in the process.
Now here is where things get interesting. All of the computers within the MGMT.com have live migrations enabled and constrained delegation has been properly configured for all of my Hyper-V servers. Live migrations within this environment work exactly the way that they are supposed to.
One day last week, I was a bit sleep deprived and I made a careless error. I logged into one of the computers in my MGMT.com domain, but I accidentally entered lab\Administrator as the user name. My login was successful in spite of the fact that I was using a user account from an incorrect domain because I have all of my domains configured to accept the same username and password combination.
As you have probably already figured out, I logged into the Hyper-V Manager and attempted a live migration and the live migration failed, citing the error shown above.
The reason why this error occurred was because Kerberos constrained delegation is configured at the Active Directory level. Because I had accidentally logged into an invalid domain, I was not actually authenticated into the Active Directory, which caused Kerberos not to function properly.
The Virtual Machine Cannot be Moved to the Destination Computer
Another very common error message is 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. You can see the actual error message shown in Figure B.
Figure B: The live migration process can fail as a result of differences in host server hardware.
As you have probably already guessed, this error occurs because the destination host server’s physical hardware is too different from the physical hardware that the virtual machine is currently running on. Specifically, it is the server’s CPU that is too different.
To show you what I mean, let’s take a look at the systems that triggered this particular live migration error. The error message shown above was caused when I tried to move a virtual machine that was running on a server named Lab7.mgmt.com to a server named Lab2.mgmt.com.
The Lab7 server is an older system, and if you look at Figure C, you can see that this server is equipped with an AMD Athlon ™ II X4 630 Processor running at 2.8 GHz.
Figure C: This server is equipped with an AMD Athlon ™ II X4 630 Processor running at 2.8 GHz.
In contrast, Lab2 is a much newer server. If you look at Figure D, you can see that Lab2 is running on an AMD FX ™ 8120 eight core processor running at 3.12 GHz.
Figure D: Lab2 is running on an AMD FX ™ 8120 eight core processor running at 3.12 GHz.
Even though both servers have AMD processors, one server has an older quad core processor, while the other has a newer eight core processor. These processors are simply too different from one another for live migration to occur in the normal way.
So how do you fix this problem? Well, assuming that new hardware is out of the question, the solution is to use Hyper-V’s Processor Compatibility feature. The basic idea is that you can disable the virtual machine’s ability to use advanced CPU features. By limiting the virtual machine to using only standard features, it becomes possible to live migrate the virtual machine.
Before you attempt this technique, there are a couple of things that you need to know. First, using CPU compatibility mode diminishes the virtual machine’s performance. Second, you will have to momentarily shut down the virtual machine to enable (or to later disable) CPU compatibility mode.
With that said, shut down the virtual machine. Next right click on the virtual machine within the Hyper-V Manager, and select the Settings command from the shortcut menu. When the virtual machine Settings screen appears, expand the Processor container and select the Compatibility container. Now, select the Migrate to a Physical Computer with a Different Processor Version check box, as shown in Figure E, and click OK.
Figure E: Select the Migrate to a Physical Computer with a Different Processor Version check box.
Once the virtual machine boots up, you should be able to live migrate it. It is highly recommended however, that you disable Processor Compatibility mode after the live migration completes. Of course doing so requires you to shut down the virtual machine again, so you may not be able to disable compatibility mode immediately.
Conclusion
As you can see, there are a number of different conditions that can lead to a live migration failure. Fortunately live migration problems are normally relatively easy to resolve. In the case of host servers with different CPU versions, it is highly recommended that you only enable Processor Compatibility mode on a temporary basis.
If you would like to read the other parts in this article series please go to:
