Looking for a best practices guide: complete cluster replacement

[timothyn]

Hi,

I've been tasked with commencing the complete replacement of our current ESXi 5.0 U2 hardware environment with a new cluster of servers running 5.1.

Here are the basics:

Currently HP Blade Server Chassis with 6 hypervisors running ESXi 5.0 U2, Enterprise license, around 100 or so VMs running various OS's - mainly MS 2003 R2 and 2008 R2, data stores on SANs connected via 1GB ethernet connections. 

Planning to run 7 independent servers as a cluster with ESXi 5.1, Enterprise License, connections to SAN to be improved to 10GB ethernet or fibre.  The VMs range in importance from "can be rebooted after hours" to "must not be restarted or it will cost us money in downtime".  (Looking for any options to live-migrate where possible although I have my doubts this will be an option given the inter-cluster plans)

I'm looking for a Best Practices Guide (or combination of guides) that will help me determine the best way to plan for the VM migration - especially in light of the fact that the new cluster will not be part of the existing one.  Also in light of the fact we cannot (due to firmware issues on the blade chassis) upgrade to 5.1 prior to this work...

Any pointers in the right direction would be great - not looking for a handout, just the signposts people

Cheers.

[weinstein5 · Accepted solution]

Welcome to the COmmunity - Since vCenter 5.1 can manage an ESXi 5.0 host just one at a time bring the 5.0 hosts in to the 5.1 environment and vmotion the VMs to the new hosts - since both environment will see the same SAN there will be no need to storage vmotion -

[timothyn]

Hi weinstein5,

So to clarify, are you saying a vCenter server can manage two (or more??) distinct clusters at the same time and manage the relocation of a VM from one cluster to another?  If so, what prerequisites exist for such a move apart from vMachine versions (ie, cannot move a v9 machine to a 5.0 environment etc)?  Is this handled as a 'vMotion-type' event or must we shut down the guest VM and use a 'vConverter-type' export/import approach? I'm just concerned about downtime (as we all are) during this mass-migration.

And, on the vCenter server - do we "re-use" the existing 5.0 U2 instance and add the cluster or so we install a new instance under 5.1 and make it aware of the older 5.0 U2 cluster?

Thanks for any information as this maybe the silver bullet for us to make an otherwise difficult (read: mountainous) task easier.

Tim.

[BenLoveday]

Hi Tim,

As weinstein5 said if you upgrade your vCenter to 5.1 it can manage both clusters running different versions. You can also vmotion/svmotion VM's in different clusters within the same datacenter. However, there are some caveats 🙂 I recently did a similar migration although it was between 4.1 and 5.0. The main issue I hit was the differences in the EVC mode on the clusters. Unfortunately the old cluster had been set to a level that wasn't compatible on the new hosts which meant that all of the VM's had to be shut down. Check your EVC mode first, hopefully your new cluster can be configured to the same EVC mode, at least for the migration and upgraded later.

Other than that if both clusters have the same storage presented, etc, you should be fine. Oh, also check your vswitches between clusters, particularly if migrating from standard to vDS in one hit, you need to juggle this carefully 🙂

Cheers,

Ben Loveday