Migration will cause the virtual machine’s configuration to be modified

Posted by Duncan Epping in January 2nd, 2008
Published in Server

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?


« OVF Tool and Nostalgia
Virtual Machine High Availability »

10 user comments or pingbacks in this post

Follow-up this post comment rss or leave a trackback
1. William Patton said,
January 8th, 2008 at 00:37

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?

2. John Gallucci said,
January 23rd, 2008 at 04:07

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.

3. John Gallucci said,
January 23rd, 2008 at 22:42

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.

4. Duncan Epping said,
January 23rd, 2008 at 23:20

That’s weird. But resetting is fine indeed if you don’t cross migrate… In noticed the same.

5. Joshua said,
March 31st, 2008 at 16:54

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

6. KIM said,
May 27th, 2008 at 01:39

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!

7. Mick said,
July 2nd, 2008 at 04:41

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.

8. Duncan said,
July 2nd, 2008 at 11:54

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.

9. Sascha Reuter said,
July 21st, 2008 at 14:55

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?

10. Steven Johnston said,
July 28th, 2008 at 14:50

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”

Leave A Reply Below

Currently browsing Migration will cause the virtual machine’s configuration to be modified

 Username (*required)

 Email Address (*private)

 Website (*optional)

Topics Search

Yellow-Bricks recommends:







VMware Fusion and VMware Workstation: Support Yellow-Bricks and get a 10% discount on select VMware products.

Train Signal:
Learn Virtualization technology with Train Signal. Support us and learn how to fully utilize VMware products at the same time! Click here for more info!

Advertisements

Recent Comments

Tags

Info