vSphere Upgrade Saga: Finish vSphere 6.7 Upgrade

In the last two vSphere Upgrade Saga posts, I completed the pre-ESXi upgrades and then the ESXi upgrades. Now it is time for the last bit of the upgrade to happen: specifically, VMware Tools, virtual hardware, and VSAN disk format. There are some new features within the HTML 5 client for vSphere 6.7 that make this so much easier.

First: VMware Tools

VMware Upgrade Manager has a new feature you need to enable in order to use. That is the ability to upgrade VMware Tools. This will allow you to scan all your VMs for those VMs that need VMware Tools upgraded. Find out which are guest managed, and those that are so out of date that updates will be difficult.

I normally upgrade VMware Tools in a specific order: a test VM first, then my AD server, and then everything else Windows related. Upgrading my View requires me to upgrade the golden image (after snapshot deletion) and not the individual desktops.

The first time I used the VMware Tools Scan option, there were no issues. However, after an attempted upgrade failed, I started to receive some weird “Unsupported enum” errors. It took me many days to figure out which VM had the issue and why. At first, I thought it was my View replica, but it ended up being a Windows 2008 R2 machine that failed to upgrade VMware Tools properly. The error still persists.

Once I had the VMs with issues on one host, I was able to use the VUM upgrader for everything else. However, it seems VUM times out long before my console, so I ended up needing to clear my cookies and cache far too often. Whenever a timeout occurred, it was required. It happened often during this process.

It took a while, but all the tools are updated now. Finding the faulty VMs took the longest time. I still get the error, but at least I know what causes it now: failed VMware Tools upgrades.

Also, note there is a snapshot involved. You will need to commit all those snapshots.

Second: Virtual Hardware

Similar to VMware Tools updates, the new HTML 5 client has the ability to upgrade your virtual hardware with very little fuss. The process is to select the VMs to upgrade. Then the automation kicks in. The virtual hardware is updated, and then a reboot happens.

This combination is often not acceptable for critical systems. I generally set those to upgrade on the next reboot of the VM. If you wish to do things this way, the VUM update process is not the best approach.

For that, you need to use the Compatibility menu item of the specific VMs.

Once more, I tend to update my critical systems after a suitable test period and usually all by themselves just so I can verify that nothing is broken as a part of my normal process to maintain compatibility.

VSAN Filesystem Upgrade

Upgrading my VSAN filesystem to the latest version was seamless and easy. I did not have to evacuate any data as I was going from the previous version to the latest. However, if the original version had been old enough, the upgrade path would have been more troublesome.

VMFS Upgrade

I could not upgrade my VMFS datastores at all. To do so would have required me to evacuate the datastores, then re-create them. In the past I was able to reformat quite easily. I chose not to upgrade using that method. So now I have a mix of VMFS version numbers in my vSphere environment.

The End?

This is the end of my vSphere Upgrade Saga for vSphere 6.7. Take a look at these posts for previous details:

This upgrade had lots of moving parts for me, as everything had an upgrade. Now I use VUM to keep everything up to date. There will be a future article on just NSX upgrades, as that itself had more than was mentioned within this series.

vSphere 6.7 is now mine to use!