With the release of vSphere 6.7 Update 2 (GA today and ready for download) folks are chomping at the bit to upgrade in order to take advantage of some of the great new features which are available in this release. There is a lot of information out there on how to upgrade vSphere so in this post I wanted to provide an overview of planning an upgrade of a vSphere (vCenter and ESXi) environment.
Proper planning of a vSphere upgrade can reduce the frustrations, the headaches, and the impacts on operations (usually the cause of frustrations and headaches) which can happen if things go sideways during an upgrade due to something which may have been missed or overlooked. The planning can also help ensure your environment is prepared for future releases. If you spend a little time on planning the vSphere upgrade it can be a fairly painless process with no, or minimal, impact on the workloads and solutions running in and supporting the environment.
There are a few very important tasks which should be part of the upgrade planning process:
Review Release Notes
Validate VMware Product Interoperability
Determine the proper upgrade sequence of VMware products
Verify Hardware Compatibility
Validate 3rd Party Product Support
Determine Architecture Changes
In today’s datacenter VMware products provide so much more than just consolidation through server virtualization. VMware provides solutions for infrastructure automation, infrastructure monitoring, network virtualization, desktop virtualization, storage, data protection, disaster recovery, hybrid cloud, and more. At the core of many of these solutions is VMware vSphere which includes vCenter and ESXi.
With vSphere being the core technology supporting so many VMware products and solutions it becomes very important to understand the dependencies in the environment and the impact an upgrade may or will have on these dependencies and solutions. I see it more often than I would like where a team upgrades a vSphere environment and the upgrade has a negative impact on other solutions (both other VMware solutions and 3rd party solutions) in the environment. This can be avoided with a little research and planning, so let’s look at these tasks in the upgrade planning process in a bit more detail:
Review the Release Notes – Do not skip this!!!
The release notes will provide you with information on the new features and fixes available in the release. More importantly the release notes will point out any known issues at the time of release. The VMware vSphere release notes can be found in the VMware vSphere Product documentation. Taking the time to read through them will likely prepare you for any potential “gotchas” you may encounter during the upgrade process. If you are upgrading across several versions, for example from vSphere 6.7 to vSphere 6.7 U2, even though the upgrade is a single step (you don’t have to upgrade to U1 and then to U2) make sure to review the release notes for all versions from where you are starting to where you will end up.
Validate VMware Product Interoperability
If other VMware products are in use in the environment it is important to ensure interoperability between versions. To ensure interoperability use VMware Interoperability Matrix to determine what versions of what products are supported with the version you are upgrading to. The VMware Interoperability Matrix should be checked anytime you are upgrading a VMware product. Determine the version required and then update the products, if required, in the correct sequence. If you are running a vCenter Server on Windows and you are not using the embedded database you should also check the Database Interoperability Matrix to ensure the database platform you are using is supported (The upgrade could provide the perfect opportunity to migrate off Windows to the VCSA, more on that later).
The image below provides and example from the VMware Product Interoperability Matrix which shows the SRM versions which are interoperable with vSphere 6.7 U2:
Determine the proper upgrade sequence of VMware products
Back in the day the vSphere upgrade sequence was something like this: upgrade vCenter, upgrade VUM, upgrade ESXi, upgrade VMware tools, upgrade VM Hardware, upgrade VMFS, upgrade vDS. This is pretty much the same today, but if you are running other VMware solutions/products in the environment such as NSX, Horizon, Site Recovery Manager (SRM), any of the vRealize Suite components (vROPS, vRLI, VRA, etc), etc… these products, if they require upgrades (see the VMware Product Interoperability Matrix), need to be part of the upgrade sequence. It is important to upgrade these products in the correct order to ensure compatibility and interoperability. For vSphere 6.7 the update sequence for compatible VMware products can be found in KB53710.
Verify Hardware Compatibility
New vSphere releases bring changes to supported hardware. New hardware is added to the VMware Hardware Compatibility List (HCL) and older hardware may fall off the list for a specific release. Hardware compatibility goes beyond the server, make sure you check the compatibility of you NICs, HBAs, storage arrays, and other hardware components which support the vSphere environment. It can be a bit tedious but it is an important step. The last thing you want is to upgrade an ESXi host and your BIOS, HBA or NIC is no longer supported and is no longer recognized in the host. The VMware HCL should be checked prior to any upgrade to ensure your hardware and the associated firmware is still supported.
The image below provides an example from the VMware HCL which shows which vSphere versions are supported on a Dell R730 Server:
Supported server BIOS and firmware versions can also be found in the VMware HCL as shown in the example below:
Many hardware vendors (Dell, Cisco, HPE, etc) provide custom ESXi images which contain drivers and agents which are supported on their platforms. Check with your hardware vendor to determine if you should use one of these vendor provided images.
Validate 3rd Party Product Support
This is probably the thing folks most often forget. Whenever there is a new release you can almost always find a few post in the VMware forums, other tech forums, and social media which go something like… “I upgraded to vSphere x.x Update x and it broke my (insert your backup product here).” I want to make sure this is clear: the upgrade did not break your (insert your backup product here). It is important to take the time to determine/understand what products and solutions in your environment integrate with the vSphere environment and to make sure that these products support the version of vSphere you are upgrading to. Check with the 3rd party vendors to ensure that the upgrade will not impact the operation of, or the supportability of, their product.
Determine Architecture Changes
New components, new platforms, new/updated topologies, depreciated products, what is supported or unsupported…
A new release of vSphere typically brings architecture changes. Previously supported topologies are deprecated, the future state of how components will be deployed is announced, and such. The upgrade process may also provide the opportunity to change the way your environment is deployed to ensure you remain in a supported state or to ensure you are prepared for a future state. Probably one of the best examples of this is the vCenter Server Appliance (VCSA). The upgrade may provide the perfect opportunity to move from a Windows vCenter Server to the VCSA. There are lots of reasons and benefits for migrating to the VCSA and that is not really what this is about. The point is it, since you are planning the upgrade process this may also be the time to plan architecture changes as part of that process. The best place to get information on any architecture changes or depreciated topologies is in from the release notes, the vSphere Documentation, and the VMware vSphere Blogs.
Take the time to plan your upgrade, hopefully these tasks and resources will help with that process. If you have questions reach out to your VMware account team, VMware support, the VMware community, or your trusted VMware partner. (We)They are there to help. The upgrade process is not difficult it just needs to be planned out in order to ensure flawless execution and to minimize the impact on the services and solutions the environment is providing. Plan, upgrade, enjoy the new features.
For you damn the torpedo, full speed ahead, bleeding edge guys who are upgrading to vSphere 6.7 U2 this weekend – at least take a few minutes to look over some of these tasks (at the very least read the release notes), make sure your 3rd party products are supported (especially your backup solution), then start clicking buttons and good luck have fun (it’ll probably be fine, right?).
If I missed something or if there is something else you do to ensure a successful upgrade drop a note in the comments.
