Mixing ESX 3.5 and ESX 3.5u3!! Urgent!

[Gr3yh0und]

Hi guys,

I have got a ESX-Cluster with 3 Servers. I got another fourth server where i thought it would be nice to install the newest ESX Server Version (3.5u3 123630).

The old ones are running 3.5 BUILD 64607. I added the new server to the cluster, tried to migrate the first VM and get that warning:

"Migration from ESX-3 to ESX-4: Migration will cause the virtual machine's configuration to be modified, to preserve the CPU feature requirements for its guest OS."

Is this dangerous for my VMs? Is it a one-way-migration?

Is it usefull to use two different ESX Versions in a cluster or should i reinstall the 4th server with the old ESX 3.5 version? Through the point, that the VMs are essential, i can't easily upgrade the three old Servers to Update 3... (I cannot see the point or heavy improved features...)

[SuryaVMware]

Apparently there is a know issue with migrating VMs from ESX 3.5 to ESX 3.5u3 and the VMware HA has some issues too.

follow the thread below and look for the workaround.

http://communities.vmware.com/thread/179159?tstart=0

-Surya

[JonRoderick]

Hi

don't worry, this probably isn't going to blow everything up. The CPU masking operation takes place because (I think) U3 can leverage more hardware CPU features than pervious versions - to preserve the integrity of the VM and ensure it's operational steadiness during a vmotion event, CPU features from the new U3 host are 'masked' in the VM vmx file. VMware will carry out this task automatically when the vmotion event takes place and is a permanent change so any vmotion events that take place afterwards will occur without any intervention.

You might want to enable EVC (if you're using Virtual Center) - this will take care of the masking when the host joins the cluster and won't require individual VM masking to take place.

Jon

[Gr3yh0und]

Thanks for your answers.

So when i move all VM's to the Update-3 Server, the CPU Information (Thanks @ Survya for the link) is masked. Are the "old" 3.5 (without any "update") still able to work with them?

Actually it is planned to upgrade all Server to the latest release, but through the fact that a lot of colleagues are working from the other side of the planet, it is hard to find a time window where no one is working and a probable downtime is possible.

[JonRoderick · Accepted solution]

Absolutely, the mask is applied to ensure vmotion stability across all the hosts in the cluster - once you've migrated the VM to the 3.5 U3 host, you'll be able to move back and forth without any further issues.

Jon

[Allowencer]

Hi All,

My first post, but long time browser. Many times guys here have helped me so I figured its about time to add in my $0.02

Here are the new masking parameters that are added; I compared the vmx file before and after the migration:

cpuid.1.ecx = "R--RRR-0--

---

H-R"

cpuid.1.ecx.amd = "R--

---

R-"

cpuid.80000001.ecx.amd = "--

---

RR-RR--

---

"

cpuid.80000001.edx = "--R--

---

"

cpuid.80000001.edx.amd = "----

---

"

hostCPUID.0 = "0000000a756e65476c65746e49656e69"

guestCPUID.0 = "0000000a756e65476c65746e49656e69"

userCPUID.0 = "0000000a756e65476c65746e49656e69"

hostCPUID.1 = "0001067600040800000ce3bdbfebfbff"

guestCPUID.1 = "0001067800010800000822110febbbff"

userCPUID.1 = "0001067600040800000822110febbbff"

hostCPUID.80000001 = "00000000000000000000000120000000"

guestCPUID.80000001 = "00000000000000000000000120000000"

userCPUID.80000001 = "00000000000000000000000120000000"

evcCompatibilityMode = "FALSE"

Obviously based on your CPU architecture and resource configuration, these settings will be different for everyone.

Just to confirm what JonRoderick said, once you migrate forward it can be migrated back - no issues.

However, the other issue with "VM Monitoring" in HA is a problem.

-Eric