"Migration will cause the virtual machine's configuration to be modified, to preserve the CPU feature requirements for it guest OS"
I get this warning when migrating VMs from one blade to the other, both are exactly the same spec, I have compared settings and can find no difference , can anyone help ?
Have you confirmed that the CPU features are identical by using the cpuid.iso?
If not, burn the cpuid.iso (located on the ESX installation CD under /images) and boot the servers, and compare the output.
Also check and see if perhaps someone has set some sort of CPU masks (not likely), and confirm that the CPU steppings are identical as well.
###############
If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!
unfortunately we've got live VMs running on both boxes and I don't want to move them until I know what the possible ramifications are of this warning, so at this point I can't do the reboot.
I can say that they are both identical servers bought and installed at the same time (HP BL685c's, 8CPU Dual-Core AMD Opetron Processors). what I have tried is going through the other VMs and I have found 2 (out of 23) which have passed the compatability test (when migrating) without the above warning !. They are the same VMs built from the same templates as the ones that throw up the warnings.
A compare and contrast of VM settings between the VMs has not thrown up any differences (as thought - because I set them up)
What, you can't just shutdown all of your VMs and reboot your ESX hosts?
(Of course, I intended to use the cpuid.iso during a scheduled-maintenance window).
I would check the cpu stepping; on each of the ESX hosts, just run the command
#cat /proc/cpuinfo | grep step
You can also compare the full output of #cat /proc/cpuinfo between the ESX hosts and see if you can spot any differences.
###############
If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!
thanks virtualdud - ran the commands and the output was identical, save a slight difference in cpu mhz (I tried this on a 3rd test esx server - not on the san - and again the output was identical save a slight difference in the cpu mhz
eg 1
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8216
stepping : 2
cpu MHz : 2411.123
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 4810.34
eg 2
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 8216
stepping : 2
cpu MHz : 2411.109
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 4810.34
cheers again..I'll award points etc later..
I'm getting the same exact message. I am also on BL685c's. The strange thing is I was able to do a vmotion from one to another without the error message. Now I am trying to vmotion them back and I get the message.
We had something like this on BL460c's as well. We found that the firmware on one blade was not identical to the others, and we suspect that the blade profile might have some how been corrupted. We were right in the middle of testing 'failover' blade scenarios, so it not obvious what the root cause was at the time.
Getting this same message while VMotionning a VM from 3.01 to 3.5
Checked the BIOS versions on the BL460's but they are identical.
Edit:
Aaah, already a topic about this message in conjunction with ESX 3.x and 3.5
I've just had exactly the same issue between 4 Dell PowerEdge 2950's. The issue is not the hardware for me, it is VMware Patches.
I had all 4 servers at the same patch level and as soon as I started applying the latest round of 3.5 patches i could no longer VMotion from a host of the pre-patched state to one that I had just patched without this warning showing up for all of my 64-bit vm's.
To be safe I powered off a test 64-bit vm and cold migrated it to a patched host and powered on. There seemed to be no adverse affects when the vm powered up and after I had done the cold migration I was able to vmotion between all the patched hosts without issue. I can only assume that VMware has put something in one of there latest patches which is affecting 64-bit vm's.