Since vSphere 5.5 was released in September, I’ve seen a lot of blog articles related to the upgrade process. Most of these articles deal with the implementation details of some specific step – upgrading the vCSA, migrating from an older version of vCSA, fixing SSO, etc. However, it seems like one of the most common questions in the freenode #vmware channel is still, “In what order do I upgrade my vCenter without breaking things?” Let’s answer that question at a high level, without getting into the implementation details.

This info is based on VMworld 2013 sessions VSVC5690 (YouTube) and VSVC4945 (requires VMworld login) taught by Justin King, Josh Gray, and Kyle Gleed, be sure to watch the presentations for additional details.

Before you do anything else, read the Hardware Compatibility List and Interoperability Matrix for all your components. Make sure your hardware is supposed by the latest ESXi, make sure any plugins like multipath IO are available, check other VMware components like SRM for conflicts with vSphere versions, and finally check third-party solutions like Veeam (which, notably, did not support ESXi 5.5 until a few weeks after its release). If anything in your list does NOT support the latest version, evaluate its need and proceed accordingly. All the gains in the world when you move from ESXi 5.1 to 5.5 are lost if your backup solution breaks, but if it’s some minor tool you don’t need, perhaps the gain is worth it. Same thing with SRM, or vCAC, etc. Contact your vendors and find out when they will be ready and revisit this process at that time. Let’s assume everything passes so we can proceed.

Now that you’ve determined everything will survive an upgrade, the first component to upgrade is vCenter. Plan this out. If you’re using VCSA, changing versions may require standing up a new VCSA and importing old data. If you’re on a new enough version, you can install updates on the existing VCSA server. If you’re using a Windows server, use either Simple Install (one server) or Custom Install (multiple servers) and install the correct components on each server. Modern recommendations are to use a single server when possible. If you have multiple vCenter servers, use Simple Install on the server hosting SSO and Custom Install elsewhere, or you may end up with additional SSO realms on the other servers. There’s a lot of caveats here, be sure to review release notes and try the upgrade in your test environment first. If you don’t have a test env/lab, at a bare minimum, clone the vCenter VM, attach it to an isolated network, and ensure you can log into the vSphere Web Client afterward.

Next, upgrade VUM and any plugins you use. As the plugins frequently talk to the hosts, they need to be upgraded before the hosts, and in VUMs case, we can use it to perform some of the other upgrade steps. Be aware that you will lose your VUM patch baselines when you do this, recreate as needed. Create a new base image for the ESXi version you will install on hosts. Include any VIBs required at this stage.

The third component to upgrade are the hosts. I suggest you use your upgraded VUM to create a new baseline with any host drivers and plugins and deploy that to your hosts in a rolling upgrade fashion. If you have a DRS-enabled cluster that can handle 1 node being offline (your cluster SHOULD be able to do so!), upgrading the cluster object will perform rolling upgrades for your without any downtime. If you don’t have DRS, or don’t have a cluster, enable maintenance mode and vMotion your VMs as appropriate, or commit to some downtime, and upgrade the hosts. If you don’t have VUM or don’t want to use it, you can always upgrade from an ISO or even at the CLI.

The fourth step is to update the VMs, specifically Tools and vHardware. Both are supported for N-4 versions. With Tools, this means you can go back to 4.0, but 3.x requires an upgrade. Regardless, it is highly recommended that you upgrade to the latest VMware Tools. On the other hand, vHardware upgrades are only recommended if you absolutely need a newer version for a particular feature, and then to upgrade to the minimum version that supports that feature. ESXi 5.5 will still support all the way down to vHW 4, so there’s no need to pre-emptively upgrade it. All you do is restrict what hosts could that VM – particularly important if your job involves creating OVFs that customers may deploy on VMhosts of unknown versions. VUM, PowerCLI, and the vSphere Web Client can all be helpful here. Be aware that some OS’s will require a reboot to complete a Tools update. For other OS’s, a reboot may be recommended to ensure your VM boots properly if it were ever to suffer an unplanned outage before your next scheduled reboot window.

The final step is to upgrade your vDSes and any VMFS3 datastores to VFMS5. Note that you can simply right-click and upgrade VMFS3 and it will get many of the benefits of VMFS5, but some benefits are only available on datastores formatted as VMFS5 (details). VMware’s recommendation is to create a new VFMS5 datastore and move all your data there. This may require some data shuffling, such as svMotioning/migrating all data off a VMFS3 datastore onto another VMFS3 datastore, deleting the original VMFS3 datastore, and creating a new VMFS5 datastore in that space. vDS have no similar constraints, you can just right-click and upgrade them. This is a good time to turn on vDS health checks if the previous vDS version did not have that capability.

Lastly, don’t forget to upgrade your other components like VDP, vCO, View, vCD, etc. Get rid of any snapshots that you may have created during the upgrade process. Don’t call the upgrade done until EVERYTHING is upgraded, cleaned up, and documented.

Some other tips:

• Use snapshots when upgraded your vCenter, vCO, and other vCenter-related VMs. Delete when the upgrade is complete, don’t let them hang around.
• Upgrades include a free 60 day trial license. That includes Storage vMotion, which is helpful for your VMFS3->VMFS5 efforts if your license doesn’t normally include that feature.
• There is no undo on an update. I suggested using snapshots above, which seems to conflict. What I mean is that you can use the snapshot to roll back a failed vCenter update immediately, but if you carry on with the update you’re committed. Other individual component updates may benefit from snapshots, but if you have an issue with your vCO update, it simply lets you retry the vCO update; you can’t bring the whole thing back to v5.0.
• You can set the default vHW version at the cluster level through the vSphere Web Client. This is especially helpful if you will have heterogeneous ESXi versions in your datacenter for a while as it increases portability of your VMs.