ESX 3.5 -> 4 guest migration

[timjwatts]

I've read a few documents on how to do this. One thing that bothers me is that my 3.5 installation (which I inherited) is not very well. In fact it's pretty sick. So I may have to migrate the guests at a fairly low level. Something like:

1. Shutdown guest
2. Copy over guest disk image files to new cluster (with it's own new SAN)
3. Instantiate a new guest VM with the disks attached and power up on the new cluster.

That's rather the worst case scenario. I'm hoping it won't come to that.

But are there any good documents on the various methods of migrating guests? Preferably from the command line as I have >120 guests and I want to script them in batches of 10 to run overnight, then clear up in the morning.

Cheers,

Tim

[AndreTheGiant]

You can also choose to attach the 3.5 hosts to the new vCenter and then use a cold migrate.

Andre

[timjwatts]

Hi,

Is that a host level attach (over host TCP/IP) or a case of attaching the old SAN to the new hosts?

Sorry - jumping the gun a bit as I haven't read all the docs yet... Reason I ask is the old SAN is FC so can't bet easily attached to the new cluster. But of course, full host level networking will be available between both cluster host sets.

Cheers,

Tim

[AndreTheGiant]

Is that a host level attach (over host TCP/IP) or a case of attaching the old SAN to the new hosts?

It depends on how you want migrate the VMs.

If a cold migrate with data transfert could be fine, than you can connect the hosts via network.

Otherwise, to perform a Storage vMotion you need that at least one host see both old and new storage.

Andre

[timjwatts]

Hi Andre (again).

OK - much appreciated again. The new SAN is iSCSI so in theory I might be able to couple it up to one of the old hosts if needs be.

I'll look first at the host-host transfer method.

Cheers,

Tim

[GaryHertz]

I did a migration about a year ago that sounds very similiar to yours.  Not knowing what equipment you have, how it is configured and exactly what "sick" means I can't say if this will work in your situation.

My equipment

Old

4 Enterprise 3.5 host servers

FC SAN, not compatible with 4.0

Unused Ethernet Ports

New

4 Enterprise+ 4.0 host servers

iSCSI SAN

Migration

1. Upgrade vCenter.

2. Configured new equipment and added to vCenter.  Same cluster as old equipment.

3, Connected old equipment to iSCSI SAN using extra ports.

4. Created Datastores on iSCSI SAN and made available to all servers

5. Performed live storage vMotion from command line to move guest volumes from FC to iSCSI.

6. Performed live guest vMotion from old servers to new.

7. Repeated steps 4 and 5 for all guests.

8. Once I had moved all guests, I removed the old servers from the cluster, installed 4.0, and moved them to a new cluster at a different site.

This was all done with no guest downtime.  If you don't have the extra ethernet ports, can't have old and new in the same cluster or the CPUs on the old and new equipment won't allow for live vMotion you may need to modify this plan.  You will want to upgrade the guest hardware once you have everything moved which will require a brief amount of downtime.

[timjwatts]

Thanks Gary.

"Sick" means a number of things here:

1. Occasional problems cloning (usually with what seem like deadlocks on the MSSQL database, though cannot be sure)
2. Weird behaviour in some guests like running very slow periodically (this seems to be an issue with one 32 bit guest)
3. No HA/VMotion (live) support due to mixed CPUs and either incompatibility or poor initial setup(??)
4. When cloning on a downed guest works, it is pitifully slow (1MB/sec) for reasons unknown.

It's 1,3,4 that made me a bit wary of anything "high level and clever". Downtime is not a problem - we are not a high availabilty site so I can have 10 hosts down overnight no problem.

I guess I could see what will move over "in the clever way" and if the worst comes to it, copy over the raw disk files at the VMHost level (even with SCP over the host interface) and build a new guest VM around them (majority of VMs are single virtual disk, only a few have multiple disk files). I'm not quite sure what this manual method will involve without trying some tests though...

It's 1-3 that make me slightly wary of the celver method - if the VM is screwed in some bizarre way (but we can probably assume the disk image is OK or the guest would be whining) I don't want to transfer any "screwedness" over in the process...

Cheers,

Tim