VMware Cloud Community
AndyN
Contributor
Contributor
Jump to solution

Vmotion fails with "Host CPU is incompatable...."

After setting our vCenter 4 / ESX 4 lab environment with two ESX 4 hosts, I added two of our ESX 3.5 hosts into the vCenter 4 managed environment. These 3.5 hosts had 10 identical Windows 2003 Server EE 64-bit virtual machines running on them. I then used storage vMotion (migrate) to move all ten VMs over to a LUN shared by the ESX 4 hosts and also migrated them so that they are now running on the ESX 4 hosts. They all came over fine. Powered up fine. Ran fine. vMotioned back and forth between the two ESX 4 hosts fine.

I then powered down 5 of the 10 VMs and upgraded their virtual hardware from version 4 to version 7. I powered them back up.

I also have built several new virtual machines on the ESX 4 hosts from scratch using the same process and the same image I used to build the VMs hosted on the 3.5 ESX hosts. So far, so good. I can vMotion all of the 5 VMs that are still at version 4 between the two ESX 4 hosts, and I can vMotion any of the new version 7 VMs built on the ESX4 hosts, however if I try to vMotion any of the 5 VMs that have been upgraded to version 7, I get the message below.

Host CPU is incomaptible with the virtual machine's requirements at CPUID level 0x1 register "ecx".
Host bits: 0000:0000:0000:0000:0010:0000:0001
Required: 1000:0000:0000:000x:xx10:0x10:xxx0:x001
Mismatch detected for these features:
* General incompatibilities; refer to KB article 1993 for possible solutions.

I did look at the KB article referenced, however it is all about overcoming problems with vMotioning between different processor types or levels. These two ESX 4 hosts (mp-esx-10 and mp-esx-11) are identical DL580 G5's. It's only the upgraded VMs that fail to migrate.

I shut down each ESX 4 host, rebooted into the BIOS and set the VT processor option to "disable", booted up the box, let it come completely up, then re-booted the box again, going back into the BIOS and setting the VT option back to "enable". This is not help.

Anybody else seen this one?

Reply
0 Kudos
1 Solution

Accepted Solutions
AndreTheGiant
Immortal
Immortal
Jump to solution

If you have identical CPU, then check VM configuration (into the .vmx file) to see if there are some old CPUID Mask value, and just remove them.

Then power on again the VM.

See also:

http://kb.vmware.com/kb/1993

Andre

Andre | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro

View solution in original post

Reply
0 Kudos
4 Replies
AndreTheGiant
Immortal
Immortal
Jump to solution

If you have identical CPU, then check VM configuration (into the .vmx file) to see if there are some old CPUID Mask value, and just remove them.

Then power on again the VM.

See also:

http://kb.vmware.com/kb/1993

Andre

Andre | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro
Reply
0 Kudos
AndyN
Contributor
Contributor
Jump to solution

Thank you Andre. That was it. I compared the VMX files between a newly built version 7 VM and one of my VMs converted from version 4 to version 7. Among other differences I found the following five lines:

cpuid.1.ecx = "R--RRR-0--


H-R"

cpuid.1.ecx.amd = "R--


R-"

cpuid.80000001.ecx.amd = "--


RR-RR--


"

cpuid.80000001.edx = "--R--


"

cpuid.80000001.edx.amd = "----


"

These correspond to register values found in the Level 80000001 and Level 1, under Options - CPUID Mask - Advanced....Virtual Machine Default tab in the Properties of the VM. This is far deeper into the bowels of virtual machine Properties than I have ever cared to venture.

After deleting these lines, migration worked fine. I also found that I could remove the lines by going into the VM Properties, Options - CPUID Mask - Advanced....Virtual Machine Default, highlighting the register and selecting "return to default". That will delete the masks.

A couple of questions remain. Why do the version 4 VMs migrate successfully when they have the exact same mask configuration that causes the version 7 VMs to fail? I also wonder, why these masks ever were created in the VM's properties of the old version 4 VMs. All of my ESX hosts are identical and have never had any need to use CPUID. masking. I am hoping that our thousands of legacy virtual machines that we will eventually upgrade to version 7 do not all have these CPUID masks hanging around.

Reply
0 Kudos
AndyN
Contributor
Contributor
Jump to solution

This has been confirmed by VMware as a bug. It will be fixed with the next update.

Reply
0 Kudos
VMjkasalVM
Contributor
Contributor
Jump to solution

My enviornment too has been bit by this bug. I've contacted VMware and there is still not bug fix. The issue still remains even in Updated 1. Only the work around is a viable solution. For good measure, here is a link to the official KB article.

http://kb.vmware.com/kb/1011294

VMware also stated they have seen many calls on this issue.

Come on VMware lets get this one patched!

Reply
0 Kudos