When it comes to upgrading the vSphere environment, we have to (or at least should 😉 ) prepare for it carefully. I have done many vSphere projects and in order for upgrades to be successful, it's necessary to do some pre-ugrade tasks 🙂 In this article we discuss the following topics:
- Why to perform an upgrade?
- What is the correct vSphere upgrade/update sequence?
- What should we check before the upgrade of vSphere?
Performing vSphere upgrade - main reasons
In my opinion, upgrades aren’t necessarily a good or bad idea in general, but you should upgrade only if you can point to three main reasons as follows:
- End of support for products
- New features
You shouldn’t upgrade because you feel as though you “have to” implement new technology. Instead, there should be a clear benefit for doing so, and one that outweighs the costs. Yes, yes, costs are very important... 😉
End of support
As every software, vSphere has a lifecycle, which begins when a specific version is first introduced to us and ends when VMware no longer provides support for that product. As a quick reminder, VMware provides the following product lifecycle phases:
- General availability - The General Support phase begins on the date of general availability of a Major Release (“GA”) and lasts for a fixed duration.
- End of general support - A product has reached its end of support life when it is no longer generally supported by VMware.
- End of technical guidance - if available, is provided from the end of the General Support phase and lasts for a fixed duration.
Features - our new toys and reasons to not sleep all the night 😉 Usually, a new version of vSphere or other VMware product changes existing features and adds new ones, but sometimes the changes mean that old features aren't available any more or are not supported. Some months ago vSphere 6.0 was released with some very cool features such as Virtual Volumes (VVOLs) or Long Distance or Cross vCenter vMotion. I have had recently a project where my customer wanted to achieve Recovery Time Objective (RTO) and Recovery Point Objective (RPO) - 0 for VM with 4vCPU. As you can guess Multi-CPU Fault Tolerance available in vSphere 6 can meet requirements however the upgrade of vSphere needs to be done.
Security and bugs
The next reasons are security and bugs. Upgrade should address/correct bugs encountered in prior version, however, in practice, an update should be enough. Sometimes we have to upgrade because some issues do not have workarounds but the same issues are not available in a higher version 🙂
You should make friends with VMware Compatibility Guide and VMware Product Interoperability Matrix 🙂 You can find there all important information such as storage arrays support with specific firmware or type of server. There are some really fundamental pre-upgrade tasks:
- Checking hardware and software compatibility
- Checking general interoperability
- Checking solution/database interoperability
- Checking upgrade path and sequence
Let's assume that you want to upgrade your infrastructure to vSphere 6.0. You have some HP DL380p servers and you would like to check whether there are supported by vSphere 6.0. You need to go to the VMware Compatibility Guide and choose "Systems/Servers" section as shown on the below figure. Then you need to choose product release version, partner name or keyword etc:
Ufff, your servers are supported by vSphere 6.0 😉
Because you use Site Recovery Manager for DR purpose, you would like to check what Storage Replication Adapters (SRA) are supported by SRM. You need to choose "Site Recovery Manager" section as shown on the below figure:
If you click on specific version of SRA, you can check what firmware versions of storage arrays are supported:
Checking general Interoperability
Sometimes it is necessary to keep mixed version of ESXi hosts in vCenter inventory (for example, your HP DL380p servers are not supported by a newer vSphere version). To confirm it, you should open the VMware Product Interoperability Matrix and:
- Select a Solution
- Add Platform/Solution and optionally select "Do not show empty rows"
As shown on the above figure, vCenter Server 6.0 supports ESXi hosts 6.0 and 5.x as well.
Checking Solution/Database Interoperability
Some VMware products use databases. It is necessary to check if databases are compatible. For example, you would like to continue using vCenter Server installed on Windows (even my vCenter on Windows vs vCenter Appliance (VCSA) post 😉 ) and database located on Microsoft SQL 2014. You can open the Solution/Database Interoperability and confirm the compatibility:
- Select a VMware Product and Version - VMware vCenter Server 6.0
- Add Database - select Mictosoft SQL Server 2014 Enterprise - 64-bit
Checking Upgrade Path
When you do an upgrade, you would like to do it directly (e.g. from 5.1 to 6.0 but no 4.1 to 5.5 and then 6.0). You can check the upgrade path in VMware Product Interoperability Matrix as well.
vSphere upgrade/update sequence
Ok, you have checked compatibility all your products and hardware. Which product should be upgraded first? Fortunately there are some VMware KB with correct upgrade/update sequence:
- Update sequence for vSphere 6.0 and its compatible VMware product
- Update sequence for vSphere 5.5 and its compatible VMware product
- Update sequence for vSphere 5.1 and its compatible VMware product
So based on upgrade sequence for vSphere 6.0 and compatible VMware products, let's assume that you have the following products in your environment:
- Backup solution (NetBackup)
- vCenter Server
- vCenter Site Recovery Manager
- ESXi hosts
- vSphere Replication
The supported upgrade/update should be as below
- If Applicable/necessary, update/upgrade the NetBackup environment.
- If Applicable, upgrade the External vCenter Single Sign-On instance
- Upgrade vCenter Server
- Upgrade vSphere Replication
- Upgrade vCenter Site Recovery Manager
- Upgrade ESXi
So as shown above, you should consider not only VMware but also other thirdy party softwares such as:
- Backup/recovery solutions
- Automation tools
- Monitoring tools
- Workflows /orchestators
For example, if you do not confirm that a backup solution you use supports a version of vSphere/vCenter you want to upgrade to... you could not able to backup your VMs (or at least it could not be supported by backup vendor). The VMware policy concerning backward and forward compatibility is for VDDK to support N-2 and N+1 releases, however your backups solution may not support a correct version of VDDK.
I have shown some fundamental steps that you should do before the upgrade of vSphere products. The upgrade needs to have a project plan as well.