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!

Comments

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host...
Read more

PowerShell Sorting by Multiple Columns

PowerShell's Sort-Object cmdlet is super useful, especially when preparing output for human consumption.  A few people have found my blog while looking for more information about its use, specifically while looking for how to sort by multiple columns (well, properties, technically).  I've never done so (much less written about it), so I hope those folks found answers elsewhere.  But, it got me curious... and it turns out that it's really easy. The Technet article on Sort-Object has the answer directly spelled out: just use commas to create a list of properties to sort by (in order to precedence).  Let's look at some examples!  First, prepare a variable with some good sortable data: $myData = get-eventlog System -newest 25 And then we can get to sorting!  Say you want to sort primarily by EntryType (Warning, Information, Error) and then by Source.  Easy-peasy: $myData | sort EntryType,Source How about if you want it to be in descending or...
Read more

Deleting Orphaned (AKA Zombie) VMDK Files

A problem that most Virtualization Administrators need to deal with is Orphaned VMDK files (or Zombie VMDK files, as some people call them).  These are Virtual Machine hard drive files that are just hanging out, taking up storage, but are attached to no VMs.  How can this happen?  Well, the most common way is when an administrator needs to delete a VMDK but isn't quite ready to commit... so, after pressing "remove", they select "remove from virtual machine" rather than "remove and delete files".  The intent is always good: "I want to be able to restore this if it turns out to be necessary... so I'll just come back and delete it next week if nothing breaks!"  But, of course, next week something else happens and the file doesn't get deleted.  After a little while, it turns into "which files did I rename, again?" and nothing seems to happen. So, how do you deal with these orphaned files?  Well, a few years ago I found a scrip...
Read more