Preparing to Upgrade VMware vSphere

Introduction

I know, I know. VMware vSphere upgrade? That doesn’t really sound scary, and it generally isn’t. Still, many admins tend to forget that with every upgrade comes proper planning, collecting requirements, and understanding compatibility and prerequisites. Therefore, they miss the part to review how other VMware products are compatible with the new vSphere version or determining which Upgrade Paths are supported.

So, here comes the purpose of this text: covering key things that you need to take care of before upgrading your VMware vSphere. Also, a lot of those aspects work with the other VMware products as well.

Interoperability

I will assume that the first thing every admin wants to know before upgrading the system is whether the other products will continue to work as they used to, and that is a good question indeed. What if they will work differently, or worse, aren’t supported at all? So, to avoid all the headaches, you’ll need to check for Interoperability with VMware Product Interoperability Matrices. That way, you can see how this version of the product is compatible with the other solutions in your virtual data center.

For example, if you were to pick, say, VMware vCenter 6.7 Update 2, you can see it plainly that it is compatible with VMware ESXi 6.5 Update 2 and 6.0 Update 3, but not with ESXi 5.5 Update 3:

Aside from VMware products, in particular, it won’t hurt if you also check for third party software, backup tools, active scripts, various frameworks, API, etc. You have to make sure it will remain working after the upgrade, so find a time to go through the manufacturer’s documentation.

Determining Upgrade Paths

On the same resource, there’s a tab Upgrade Path to verify whether the currently installed versions of your products have a direct upgrade path to the new version of vSphere.

Here, for example, you can check out the possible upgrade paths for VMware vCenter Server:

You can see for yourself that vCenter 5.5 Update 2 doesn’t have a direct upgrade path to vCenter 6.7 and later versions. No wonder why it happened that way: the code of the product is so obsolete that there’s no reason for the manufacturer to adapt this product just to keep a few dinosaurs alive.

However, if you look closely, you’ll see that operating an outdated product is not always an only reason for the absence of a direct upgrade path. At least this isn’t the case with vCenter 6.5 Update 2 and vCenter 6.7.

In fact, it’s more simple than it looks like. It’s a Back-in-time Upgrade scenario: vCenter 6.5 Update 2 was released later than vCenter 6.7, which also results in code differences. I’ll talk about it a little bit later.

One more thing. You know that many admins prefer to start with a clean slate when they deal with major software upgrades. Still, this way has its own underwater rocks, including the preserving the historical data, complicated configurations, etc. Nevertheless, if you do have an easy way to install a clean version of the product without great difficulties, you definitely should go with it.

Back-in-time

Now, let’s clarify what the deal is with that Back-in-time Upgrade. Such a scenario occurs when an upgrade path eventually results in the deliberate regression of code and security fixes. Even the smallest details can trigger this unpleasant outcome. For example, if an old field was deleted or a new field was added in the database of vCenter 6.5 Update 2, vCenter 6.7 wouldn’t know it, although it does have the later version.

Sometimes VMware lets these things pass, but there’s always a warning about the regression risks. For instance, you can upgrade VMware vSphere 6.5 Update 2d (release date 11.29.2018) to vSphere 6.7 Update 1 (10.16.2018).

Since you really don’t want to get confused with all the build numbers, it’s extremely helpful to check this. Here, you can look up the upgrade path matrices that can help you to find out whether the Back-in-time Upgrade is a threat in your case or not.

These are the matrices for ESXi and vCenter:

Now we can see actual numbers and release dates, including such minor updates for vCenter and ESXi upgrades as 6.5.0 Update 3f (build 15259038):

Planning the Upgrade

When you’ve established a proper upgrade path for you, it’s time to develop the upgrade’s inner order. Not only does it take care of the upgrade steps per se, but it also prepares for a situation where something goes wrong (you can read about vCenter roll back here). It also won’t hurt if you’ve had a backup copy of your configuration at hand before the upgrade.

You just have to remember that while upgrading VMware vSphere, you better start with vCenter management servers: ESXi hosts only come after that. Before the procedure, find all you need to know here.

The scheme looks like that:

If you have vCenter Server on Windows, you should use Migration Assistant and Migration Tool utilities: they will walk you through the path to vCenter Server Appliance (vCSA) step by step.

According to VMware, you only need two primary things to move from vCenter to vCSA:

Migration Assistant – console utility that you activate before the vCenter migration master. It determines the migration requirements and generally points an admin in the right direction.
Migration Tool – migration master that is available from the vCenter’s main distributive.

All in all, the vCenter upgrade algorithm looks something like that (more details here):

Important: remember about Virtual Hardware upgrade when the migration is done.

There are three ways to perform VMware ESXi upgrade:

Manual (through GUI with the use of CLI or scripted installation)
Auto Deploy (host upgrade)
vSphere Lifecycle Manager (the replacement of Update Manager)

Post-Upgrade Procedures

Now you may think that it’s time to call it a day, but we aren’t done just yet: don’t forget about the post-upgrade procedures. For vCenter, these are (look it up here):

Verify the successful migration (details are here).
Log in to vCenter Server by using the vSphere Client (details are here).
Decommission the old Platform Services Controller (details are here).
Install the VMware Enhanced Authentication Plug-in (details are here).
Perform the components reconfiguration.
Verify the correct working of the authentication and identification workflows.
If you’ve successfully migrated vCenter Server on Windows to vCSA, you’ll have to recreate the local OS users in vCenter Single Sign-On and assign them the necessary access rights (details are here).
Don’t forget to check all your additional vCenter plug-ins and modules (details are here).
Monitor and Manage historical data migration (details are here).

For VMware vSphere / ESXi, the procedures are as follows (all documentation is here):

Check the upgrade logs with vSphere Client.
After the upgrade is done, reconnect the host (click on Connect in the ESXi context menu).
Assign VMware ESXi license. You can download it from My VMware.
The host sdX devices also require reconfiguration. Also, take a look at the scripts using these device numbers because those will be renumbered when you’re done with the upgrade.
Perform Virtual Hardware Version upgrade via vSphere Client or Lifecycle Manager.
Configure vSphere Authentication Proxy services (the previous versions aren’t compatible with VMware vSphere 7.0). You can find a lot more information here.

Conclusions

Of course, this article is just a short guide because it’s impossible to mention every single detail. However, since it seems we have already covered the most crucial aspects, this should be enough for anyone to go through the upgrade without any fuss. Good luck with upgrading your VMware vSphere!

VMware vSphere: Time to Prepare for an Upgrade!