VMware Cloud Community

vMotion CPU compatibility issue

I've read through some of the discussions around CPU compatibility, but I think I have an odd situation. Sorry if this has been covered already.

I have 7 ESX servers (IBM x3550, Xeon E5345), all identical builds. For some VM's (not all) I get CPU compatibility errors when trying to do vMotion. The really silly thing is when I do this with Storage vMotion as the host (and CPU) stays exactly the same.

I've masked the NX bit from the VM's, I've enabled Enhance vMotion compatibility, and still get the error, but only with some VM's. For example, I have 3 identical 64bit Ubuntu machines, 1 of them migrates fine, the other 2 don't. I have 2 Windows 2003 - 32 bit domain controllers, one of them migrates, the other doesn't. It doesn't seem to be limited to any specific host either. The exact error is always the same.

"Host CPU is incompatible with the virtual machine's requirements at CPUID level 0x1 register 'ecx'.

Host bits: 0000:0000:0000:0000:0010:0010:0000:0001

Required: 1000:0000:0000:000x:xxx0:0x1x:xxx0:x001

Mismatch detected for these features:

  • General incompatibilities; refer to KB article 1993 for possible solutions"

I've read through the KB article, and read through the forums, but they appear to refer to different architectures, which I haven't got. I don't really want to modify the mask bits as ultimately there should be no problem in using Storage vMotion to migrate to itself!

Thanks in advance!

0 Kudos
1 Reply

(EDIT: see http://communities.vmware.com/thread/227172)

Leaving bottom message for reference but does appear to be the same issue so I'll give a check to "reset all" otherwise will wait for the patch.

(former message hereafter)


you're not alone...

I run a 3 x HP DL380G5 cluster, 2 x Xeon 5440's each and have exactly the same situation. I run ESXi 4.0 rev 164009 on these three hosts.

Running with or without EVC (45 nm Core2) brings the same message than you with same register 'ecx'.

Yes, VT and so on are enabled and have always worked - and I'm speaking here of two 32 bits VMs refusing to move while the others are OK.

I discovered the issue while I wanted to set one host in maintenance mode to apply latest patches on it but I cannot shutdown those two VMs right now so will be stuck with this for at least the day. Did you get any feedback?




-- ML
0 Kudos