I now have a cluster of ESX 4.0 hosts running with EVC enabled, in “Intel Xeon Core 2” mode. It’s been working okay so far (there are some rough edges here and there, nothing showstopping) and this morning I decided to convert a couple of my VMs to the new ESX 4 hardware format, “VM Version 7.”
As soon as I upgraded the virtual hardware the VMs in question stopped being able to VMotion at all giving me the error:
“Host CPU is incompatible with the virtual machine’s requirements at CPUID level 0x1 register ‘ecx’.”
no matter where I tried to VMotion it to (even the same CPUs on a different machine). Not cool. These were VMs that were working flawlessly as VM Version 4. One support case later and a gentleman named Rob pointed me to KB article 1008315, suggesting that I check my .vmx file for CPU mask information and remove it.
Sure enough, somewhere along the line my .vmx files grew some unwanted cruft, in the form:
cpuid.1.ecx = "R----R----R--R-0-----------H-R--" cpuid.1.ecx.amd = "R---------------------------R---" cpuid.80000001.ecx.amd = "------------------RR-RR---------" cpuid.80000001.edx = "----R---------------------------" cpuid.80000001.edx.amd = "--------------------------------"
and now EVC, though it should ignore that extra stuff, doesn’t seem to anymore with VM version 7.
Via vCenter, I edited the settings of the VM, went to the Options tab, then to “CPUID Mask” and clicked the “Advanced” button. Clicking the “Reset All to Default” button did the trick.
Great tip, Bob. Odd that the upgrade migration breaks things like that. You’d really think they’d check stuff like that.
One of these days, I’ll get time to really play with VMware, and I’m looking forward to it.
Yeah — I’ve run into a bunch of stuff like this now. VMware’s x.0 software is usually pretty bad, and with bugs like this, and the recent data loss issues with RAID controller caches, etc. I’ve suggested to a few people that they wait for a while before upgrading.
Of course, since VMware isn’t doing decent testing, if everybody waits then bugs won’t be found as rapidly…