VMotion between 3.0.2 and 3.5

[badazws6]

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. The upgrade guide says you should be able to do this... Any thoughts?

[Milton21]

I was running a mix of 3.0.X and 3.5. I got this message as well, but when I told it ok everything went fine and the machine was able to migrate from 3.5 to 3.0.X and from 3.0.X to 3.5 after that with no errors of messages.

[badazws6]

Yeah, mine trys to start but eventually fails.

[Milton21]

did your VC server upgrade the 3.0.X with the new "VMware connector" not sure of the name service that connects to VC

[badazws6]

I'm not sure what you are referencing but I didn't do an upgrade on my VC instance. I removed and "clean" install on the same server and then readded the hosts.

[Milton21]

Yes but when VC 2.5 sees esx server that are 3.0.x it tries to upgrade the connector to VC. To retry this install... Just remove the esx from the cluster and readd it.

[badazws6]

I removed the 3.0.2 host from the VC server and then readded with no luck. I then created a cluster and added it to the cluster with not luck.

[fmdj]

I got the same message while Vmotion from 3.02 to 3.50 host. Once done, the message never shows up again. VC is updatet from 2.02 to 2.50...

[jmiller_rcrh]

I'm running 3.0.1 on all my ESX except for one which I just clean installed today at 3.5. I'm getting the same message. I also get an "Operation Timed Out" after completing the wizard. I've called Tech Support and they're currently baffled. They've looked at my switch configs and everything. The IRONIC thing is that this same box vmotioned this morning before I changed it to 3.5.... weird.

[jmiller_rcrh]

Just an update to my adventures - I'm finally able to vmotion - sort of. The warning related to CPU feature decided to BSOD all of my 64bit W2K3 servers after I vmotion'd them. They vmotion completely but then tank. I haven't tried a 32bit yet.

[Lofty]

Message is standard whe VMotioning between hosts of differing ESX version. Once all your hosts are running the same version, it'll go away.

In the last upgrade of an entire environment from 3.02 to 3.5 that I did, I had the following happen.

You'd VMotion all VM's off a host. Pull the host down, remove it from VirtualCenter (customer didn't want the history) and do a complete re-install with ESX3.5. Add the host back into VirtualCenter, finish off network and SAN configs etc and all looked good.

However, when you got to migrate a running VM from a 3.02 host to the new 3.5 host - VMotion fails.

Soultion was to do a cold migration of only the first VM onto the new ESX3.5 host and from then on, live VMotions worked!

Happened to all 4 hosts in the environment - wierd.

Never seen this before.

[snowmizer]

Lofty, I tried your suggestion about cold migrating the first VM onto my new ESX 3.5 server and then tried to VMotion the rest of my VMs onto the new 3.5 box and still get the "Operation timed out" message. When I perform the cold migration everything is fine. The VMs I am migrating were on this host earlier today (prior to the clean install of 3.5). Has anyone else found a way to get live VMotion to work?

Thanks.

[BenConrad]

I had a similar issue after upgrading one of the 2 hosts in my test lab. Both were at 3.0.1, vMotion working perfectly. I upgraded to VC 2.5, vMotion worked perfectly. Upgraded one of the 3.0.1 hosts to 3.5.0, then 3.5.0U1. One VM migrated over to the 3.5U1 server automatically. When I manually vmotioned a VM from 3.0.1 to 3.5U1 I got the CPU compatibility message but the vMotion succeeded. vMotion back to 3.0.1 then back to 3.5U1 and the warning message is no longer there but the vmx file has been modified:

<ORIGINAL, vMotion works fine on 3.0.1>

cpuid.1.eax = "--XXXXXXXX--

---

"

cpuid.80000001.ecx = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0"

cpuid.80000001.edx = "XX0XXXXXXXX0XXXXXXXXXXXXXXXXXXXX"

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

---

"

< NEW, new additions after 3.0.1 > 3.U1 >

cpuid.1.eax = "xxxx--

---

xx--

---

"

cpuid.1.ecx = "--

---

RRR----

---

"

cpuid.1.edx = "--

---

T--"

cpuid.80000001.eax.amd = "xxxx--

---

xx--

---

"

cpuid.80000001.ecx.amd = "--

---

RRR-0-"

cpuid.80000001.edx = "--

---

H--

---

"

[espiga]

First do a Cold Migration then , you be able to vmotion whithout error .

[GraphiteDak]

This fix does not work in my environment either. I have rebuilt with 3.5.0 and with 3.5.0 update 1 and neither seem to work. 3.0.2 is fully patched also.

Update - The only way I could get it to work was to do a vmkping from one of the 3.02 hosts to the 3.50 host on the vmkernel address. Cold migration would not do it. Strange indeed.

[snowmizer]

I was able to get everything upgraded without shutting down my VMs. I had a 3.0.2 server that I was able to migrate my VMs to from my 3.0.1 servers (this worked without issues). Once I got the ESX host upgraded to 3.5 I was able to migrate my VMs to the 3.5 box from my 3.0.2 server. The last server I did was my 3.0.2 server. I was able to migrate the VMs on this host to my 3.5 host and everything worked like a charm.

[GraphiteDak]

Okay what I have found is when the 3.50 host comes up the vkernel is not pingable. The first thing that needs to be done is run a vmkping from the new 3.50 host to any of the vmotion IP's of any 3.02 hosts. Then ping from any 3.02 host back to the new 3.50 hosts vkernel ip. This seems to do the trick.

[fmdj]

So what is the preferred method migrating from 3.02 to 3.5 Upd 1 without running into any trouble? I got 4 ESX servers to update with running VMs which can be shut down only once while migrating...

[arkaries]

Well, I tried all the mention fixes..Only one that worked for me was doing the vmkping from 3.0.2 hot to 3.5U1 host and back....I upgraded 7 host and worked everytime.

Good Luck..

[GraphiteDak]

In my environment I have to ssh into the new 3.5 host that has been built and then vmkping from it to another other vkernel IP and it will start right up. vmkpinging from another host TO the 3.5 host does NOT work. The ping must originate from the new 3.5 host. Good luck.