Comments on: Migration will cause the virtual machine’s configuration to be modified http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/ Building blocks for virtualization... Thu, 18 Mar 2010 17:32:11 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Steven Johnston http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-756 Steven Johnston Mon, 28 Jul 2008 12:50:39 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-756 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" 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”

]]> By: Sascha Reuter http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-707 Sascha Reuter Mon, 21 Jul 2008 13:55:38 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-707 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 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?

]]> By: Duncan http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-646 Duncan Wed, 02 Jul 2008 10:54:14 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-646 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. 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.

]]> By: Mick http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-645 Mick Wed, 02 Jul 2008 03:41:18 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-645 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. 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.

]]> By: KIM http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-550 KIM Tue, 27 May 2008 00:39:54 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-550 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! 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!

]]> By: Joshua http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-410 Joshua Mon, 31 Mar 2008 15:54:11 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-410 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 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

]]> By: Duncan Epping http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-72 Duncan Epping Wed, 23 Jan 2008 22:20:09 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-72 That's weird. But resetting is fine indeed if you don't cross migrate... In noticed the same. That’s weird. But resetting is fine indeed if you don’t cross migrate… In noticed the same.

]]> By: John Gallucci http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-71 John Gallucci Wed, 23 Jan 2008 21:42:07 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-71 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. 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.

]]> By: John Gallucci http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-60 John Gallucci Wed, 23 Jan 2008 03:07:41 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-60 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. 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.

]]> By: William Patton http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/comment-page-1/#comment-21 William Patton Mon, 07 Jan 2008 23:37:40 +0000 http://www.yellow-bricks.com/2008/01/02/migration-will-cause-the-virtual-machines-configuration-to-be-modified/#comment-21 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 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?

]]>