vSphere 3.5 to 6.0 Upgrade procedure

Basic Assumptions:

The customer does not necessarily need access to historical performance or event data and is willing to sacrifice that.

The customer is willing to accept minimal downtime so long as it is planned.

 

1.       Backup the entire environment, including the VMs and the supporting systems and databases. (!)

2.       Stand-up the new hosts with either 5.5 or 6.0

3.       Stand-up new datastore storage for your new 5.5 or 6.0 cluster.

4.       Designate one of your new hosts to be the transition host or ‘landing zone’

5.       Add an FC HBA to this landing zone host and have it zoned so that it can see the existing VMFS3 datastores.

DO NOT UPGRADE VMFS if prompted or offered!

6.       Select a number of non-essential virtual machines to serve as a proof-of-concept.

7.       Take note of which datastore(s) the identified virtual machines reside.

8.       Systematically schedule the shutdown of the identified virtual machines.

9.       Once the virtual machines are powered-off, right-click and remove from inventory.

DO NOT DELETE. Remove from inventory.

10.   On the landing zone or transition host, browse the datastore where the VM to be migrated resides, open the folder and find the configuration (.vmx) file. Right-click on that file and choose Add to Inventory.

11.   Once the VM shows up in the new cluster, attempt to power it on. Verify that the power-on works and the system is available on the customer’s network. Note that the network port-group labels and such may be different between the old cluster and new, so you might have it edit the VM’s settings to ensure the correct port-group(s) are selected.

DO NOT UPGRADE VIRTUAL HARDWARE OR VMWARE TOOLS AT THIS TIME.

12.   Repeat as necessary until all virtual machines are moved to the new cluster.

13.   Plan an upgrade of the VMware tools (requires a reboot) on each virtual machine.

14.   Plan an upgrade of the VM virtual hardware level (requires a second reboot) on each virtual machine.

15.   Utilize VMware’s Storage vMotion to move all of the VMs to the new datastores.

16.   Remove the legacy VMFS3 datastores.

17.   Shutdown and decommission the old hardware.

 

I have done this before with 5.5 and assume that it would operate the same way with 6.0, but that is another risk that would need to be identified with going right to 6.x. You could upgrade to 5.5 and then, once completed, upgrade to 6.0.

 

Note that if any VM has an RDM, that will need to be handled separately. You can use the same process, but before you are able to decommission the old storage you will need to either migrate the external RDM to a new virtual VMDK (create new VMDK, use guest OS tools to move the data) or another form of storage based on the new array’s capabilities.