Planning VMware Upgrades

System upgrades are a fact of life in the world of IT.  As systems grow more complex and interrelated, upgrades become more and more difficult to plan, as each of those interacting systems creates a dependency that may or may not support the new version!  In the VMware world, there's a couple of great tools that I use every time one of my customers asks for help with an upgrade project... so I figured that I'd write about them here!

If the customer wants to upgrade their ESXi servers (which they almost always do), the first thing that I check is the VMware Compatibility guide.  When I'm using this tool, I typically select the new ESXi version under Product Release Version and then just use the search bar to find the hardware platform that the customer is using.  After selecting the right server, the page will show us what firmware versions on that server platform are supported (or other interesting notes to be aware of).  These days, it's pretty rare for a server platform to not support ESXi, but it's always good to check!

Once I'm sure that we don't have a show stopper at the hardware level, it's time to hit the VMware Product Interoperability Matrix.  To use this tool, you select one product and then the other, then the tool will generate a big table showing what versions are compatible between them!  When consulting these tables, it's important to consider what your upgrade process is going to look like.  Are you taking a single big outage window where everything's going to be upgraded at once (and you'll cross your fingers that no one component breaks)?  In case you couldn't tell, I'm not generally a fan of that approach, so if you're doing a phased upgrade you'll need to verify that the new versions of each component are compatible with both the current infrastructure and the new infrastructure.  That's a little abstract, so let's imagine an example.

If we've got a customer running ESXi 6.0 and vCenter 6.0 that wants to get fully up-to-date (quite a big jump), we'll need to check the compatibility matrix to see how those versions interact with the 7.0 family (quick tip: search for "ESXi" to quickly find the hypervisor, and "vcenter server" to find vcenter).  In this screenshot, I specified only versions 7.0 U2 and 6.0 U3 for ESXi to keep the chart size manageable).  Here, we can see that we've got a bit of a problem!  If we upgrade our vCenter server to any of the 7.0 versions, we'll lose our ability to manage the 6.0 ESXi servers (and of course, the vCenter 6.0 server cannot manage ESXi 7.0 hosts).

In this situation, we cannot do a phased in place upgrade directly to 7.0.  We still have some options though!  I would recommend that we either do an upgrade to 6.7 first, then up to 7.0 (always upgrading vCenter first), or we stand up a new, adjacent 7.0 environment and then use cross-vcenter migration to move VMs from the old environment to the new one (and eventually retire the old environment).  Which option is best?  Well, that depends on the resources available to this customer and on how complex the interdependencies are!  I'd lean towards the adjacent build option, but if they've got a bunch of 3rd party solutions that talk to vCenter, an in-place upgrade would almost certainly be the better approach.

vCenter and ESXi compatibility is, when it comes right down to it, simple though.  The Interoperability Matrix is absolutely crucial when planning upgrades that involve other VMware products, like vCloud Director, vRealize Operations, or Horizon.  When planning these upgrades, we'll use the exact same process as before.  If Horizon needs upgrading, check that the new version is compatible with the current vCenter server (and for good measure, check the ESXi hosts too!).  Are you upgrading the vSphere deployment in an environment that uses Horizon?  Well, check those same charts, but make sure that the new versions of your vSphere components aren't going to give Horizon a conniption!  Also, pay attention to those little circled "i" icons in the upper corner of the green checkboxes; they often specify some additional critical information that will allow you to fix a problem before it occurs.

So, that's planning VMware upgrades in a nutshell!  I hope you find this article useful!