In my last blog I talked about how the extended VMware Tools support provided by VMware helps facilitate vSphere upgrades. In this blog I want to discuss how the extended virtual hardware support also helps with upgrades and call your attention to an important distinction between the two.
Like with VMware Tools, VMware provides extended support for older virtual hardware versions. That is to say that newer ESXi hosts can run virtual machines with an older virtual hardware version. For example, vSphere 5.1 supports VMs running virtual hardware versions, 4, 7, 8 and 9. However, it is important to note that virtual machines running newer virtual hardware versions cannot run on older versions of ESXi. For example, a virtual machine running virtual hardware 9 cannot run on an ESXi 5.0 host. The following table highlights the virtual hardware version support for vSphere 4.0 and above.
It is important to consider this when planning your vSphere upgrade as upgrading the virtual hardware at the wrong time could cause problems. This point is best illustrated with a simple example.
Consider a small cluster hosting several virtual machines. This cluster is running four ESXi 4.1 hosts and the virtual machines are all running at virtual hardware version 7.
Of course you begin the upgrade by upgrading vCenter Server. After the vCenter upgrade you then proceed to upgrade the first ESXi host in the cluster. You do this by:
Placing the host into maintenance mode
Waiting for DRS to migrate the virtual machines off the host
Upgrading the host
Re-connecting the host to vCenter
Simple enough, we now have one host running vSphere 5.1 and three hosts running vSphere 4.1. In upgrade terms this is referred to as a “mixed cluster”, and because the VMs are all running virtual hardware 7 they can still run on any of the four hosts. So there are no concerns with running different versions of ESX/ESXi.
At this point you can repeat the steps to upgrade the remaining hosts, but lets say that before we upgrade the next hosts in the cluster we get called on to create a new virtual machine. As luck would have it this new virtual machine gets created on the upgraded 5.1 hosts, and without giving it much thought the virtual hardware gets set to version 9.
This now introduces a problem. Although virtual hardware 9 is supported on the ESXi 5.1 host, it is not supported on the three ESXi 4.1 hosts. Consider what would happen if the 5.1 host where to fail and VMware HA needed to restart the new VM on one of the surviving hosts? The restart would fail because the 4.1 hosts cannot run a virtual machine with the newer virtual hardware version. End result is an unexpected outage would occur.
For this reason, you should avoid upgrading your virtual machine hardware versions until after all the hosts in the cluster have been upgraded to the latest ESXi version. In addition, when creating new virtual machines you should take care to ensure that they are always created with a virtual hardware version that is compatible with all the hosts in the cluster. In this example, if the virtual machine had been created with a virtual hardware version of 7 there would not have been a problem.
As you can see, when upgrading to a new vSphere release it is important to pay attention to the hardware versions of your existing VMs as well as the hardware version of any new VMs created during the upgrade process. With this in mind let me highlight a couple of nice features introduced with the vSphere 5.1 web client that will help you do this.
Note, Virtual Machine Compatibility and the ability to set a default compatibility level are unique to the vSphere Web Client. These features are not available with the traditional vSphere client.
1. Virtual Machine Compatibility
Starting with vSphere 5.1 the web client now uses the term virtual machine “compatibility” in place of “virtual hardware”. In addition, instead of using a version number the web client now makes references to the vSphere release on which the virtual machine was created. For example, in the image below we can see the virtual machine’s compatibility is based on ESXi 5.0 (or what would traditionally be referred to as virtual hardware version 8).
This move away from a virtual hardware version number to a virtual machine compatibility level not only makes it easier to track the virtual machine capabilities (by tying it to a release and not a version number), but it also helps eliminate the pressure felt by many to continuously upgrade their VMs virtual hardware simply to “keep up” with an ever-increasing version number.
2. Setting a Default Compatibility
In addition to the change in terminology, the web client also allows you to set a default compatibility. You can set a default compatibility level at the host or cluster level. This can be handy during upgrades and when running a mixed cluster as it will help ensure that no one accidently creates a VM with a higher compatibility level than can be supported by the hosts in the cluster
One final point, unlike with VMware Tools where it is always recommended to upgrade to the latest version as soon as you can, with virtual hardware you should only upgrade when it is required. There is no need to incur any unnecessary virtual machine downtime just to keep up with the latest virtual hardware version. Upgrading virtual hardware is only necessary when required to take advantage of the newer features and capabilities.
Summary
So in summary, similar to the extended support provided with VMware Tools, VMware also supports running virtual machines with older virtual hardware versions on newer versions of ESXi. However, unlike with VMware Tools, the new virtual hardware versions introduced with each new release are not backward compatible with older versions of ESXi. This lack of backwards compatibility, if not closely monitored, can be problematic. Especially when running a cluster comprised of hosts running different ESX/ESXi versions, such as during a rolling upgrade.
To help track virtual hardware versions across your infrastructure the new vSphere web client (introduced in vSphere 5.1) uses the term virtual machine “compatibility” in place of “hardware version”. This change makes it easier to readily identify a virtual machine’s capabilities by tying it to the vSphere release on which it is based. At the same time it can help eliminate pressure to continuously keep up with an ever-increasing version number. In addition, the new web client also allows you to define a default compatibility level for any new virtual machines that get created. This will help avoid the situation where someone inadvertently creates a virtual machine with a newer compatibility level that can be supported by the host in your cluster.
I hope this blog has been helpful. Get notification of other blogs by following me on Twitter @VMwareESXi.
