When live migrating from ESX 3.0.2 to ESX 3.5 VMware gives an error:”Migration will cause the virtual machine’s configuration to be modified, to preserve the CPU feature requirements for its guest OS.” This error indicates that the .vmx file is about to be changed.
In my case VMware added the following bit:
cpuid.1.eax = “xxxx————xx————–”
cpuid.1.ecx = “——–R–RR——————-”
cpuid.1.edx = “—————————T—-”
cpuid.80000001.eax.amd = “xxxx————xx————–”
cpuid.80000001.ecx.amd = “—————————-0—”
cpuid.80000001.edx = “——————–H———–”
cpuid.80000001.edx.amd = “—–R————–H——T—-“
This CPU masking surprised me because both Servers are completely the same. Than again ESX 3.5 contains Paravirtualization and Virtualized MMU, and I can image that this functionality is exposed to the VCPU and doesn’t need to be exposed in ESX 3.0.2. Anyone else any thoughts on this?
I am looking at the same error tonight using VMotion between 3.0.1 and 3.0.2 identical servers. They have identical hardware for VMotion specifically, and this error surprised me.
Any thoughts on 3.0.1 -> 3.0.2 with this error, or any further information on 3.0.2 -> 3.0.5 with this error?
I ran into the exact same problem as well. It occurs for me during both Cold and Live Migration. That paravirtualization in ESX 3.5 is causing this issue is a good assumption, although having trouble finding it in any documentation. A good sign of this is the fact that my Windows VM left the CPU flags all empty, as previously with ESX 3.0.2, but it changes for all my Linux ones.
Another issue I am having is that some of my RHEL 4 (32-bit) virtual machines fail to boot, giving the error message “Your CPU does not support long mode. Use a 32bit distribution”. I believe this might be because some of my linux VMs were stored on an AMD server with ESX 3.0.1 and I am moving to an Intel Server with 3.5.
I would write more but I am still trying to figure this one out. From what I can see is that you must upgrade AMD and Intel hosts to the same version (in this case ESX 3.5) or else Cold migrations will fail or the OS won’t boot.
Problem solved. For some reason my Virtual Machines were labeled as 32-bit OS, when actually they had a 64-bit OS installed. This still creates a warning however when you migrade from 3.0.2 to 3.5. I believe this is neccessary because of the changes to ESX in order for paravirtualization to occur.
I have found out that when in doubt reset the advanced CPU configs to default. Keep in mind that the warning messages will reappear if you migrage accross different versions of ESX again.
That’s weird. But resetting is fine indeed if you don’t cross migrate… In noticed the same.
Hey folks, I ran into this same problem migrating 3.0.2 guests to 3.5. In my case, when 3.5 was installed, it apparently changed the CPU description from “Dual-Core AMD Opteron(tm) Processor 8220 SE” to “Dual-Core AMD Opteron(tm) Processor 8220”. It may be unrelated as my 3.5 host was a new server. After I upgrade one of my existing 3.0.2’s to 3.5, we’ll see if it modifies the CPU type again.
Cheers
This caused a Solaris 10 VM to panic every bootup. Turns out the CPU Mask added by 3.5 caused this the next time that VM was power cycled (many weeks after the 3.5 upgrade) Removing the mask fixed the VM, adding the mask breaks it again. So VMWARE are looking at that.
Nasty!
I’m also getting the error:”Migration will cause the virtual machine’s configuration to be modified, to preserve the CPU feature requirements for its guest OS.”
However, both machines involved are identical servers, both with Intel Xeon E5345 2.33 Ghz processors. The only difference is I server is running 3.5, the other is 3.0.1
will the migration be successful.
No problem, migration will be successful. But the CPU mask will change, I can imagine you would want to revert that when all hosts are upgraded.
I have also this problem, but with migration between physically identical ESX 3.5u1 hosts.
One has the patches up until April 2008, the other has the patches up until June 2008.
Can a VMWare microcode in one of the patches update cause this behaviour?
I just got this between an ESX 3.5u1 and an ESX 3.5u2 host during VMotion. There is a similar sort of change to above but with 10 more lines (I have taken out the number between the “”, it is 32 characters long). See below.
hostCPUID.0 = “”
guestCPUID.0 = “”
userCPUID.0 = “”
hostCPUID.1 = “”
guestCPUID.1 = “”
userCPUID.1 = “”
hostCPUID.80000001 = “”
guestCPUID.80000001 = “”
userCPUID.80000001 = “”
evcCompatibilityMode = “FALSE”