Unable to VMotion, incompatible CPU?

[whynotq]

I have a annoying situation, A client recently added a DL383 G2 to their existing cluster. the existing cluster contains a 385 G1 and a 585 G1, unfortunately they failed to follow the procedures and the new server is a different CPU group, however there is a mask available at Level 80000001 edx (7th bit =0) which has allowed me to get the VMotion runing between the 3 servers.

now i found a problem which i can't seem currently to answer, the client wants to upgrade to 3.5 u 1 from the current 3.0.1 environment, i upgrade VC no problems, then upgrade the new G2 server only to find i can't now VMotion to it, the VMotion validation checks OK but the process sits at 10% and eventually times out, if i do a VM cold migration i can't even power on the VM on the G2, so after 1/2 day of head scratching i rolled back to the origional 3.0.1 install and all was fine once again.

any one else seen this or anything in a document relating to changes in the CPU masking from 3.0.x to 3.5 ?

[JonRoderick]

Hi

may not be directly translatable to HP hardware but the later BIOS versions of IBM x3650 hardware turned on the 'Execute Disable Bit'. This led to vmotion problems between hosts on the old BIOS level and the new BIOS level. Perhaps something similar with your HP kit?

Jon.

[whynotq]

not sure that it is BIOS related as the mask is working fine in 3.0.1 it is 3.5 that seems to change it but i am open to suggestions so that i can go back to site and try again armed with a large number of options.

[kjb007]

If you can't power on the vm after a cold migrate, then it would be helpful if you had a vmware.log from that attempt that we could look at.

-KjB

[whynotq]

Hmmm... This looks familiar, follows the same issue i see. i have looked in the logs there are no "stand out" errors but various minor ones which i will see if i can reproduce.

http://communities.vmware.com/thread/121727