How to execute a virtual hardware upgrade — and Ctrl-Z a faulty one
Reading Time-approximately: 5 minutesAdministrators who want to get the most out of their virtualization investments will need to perform an upgrade to the virtual hardware, and know how to undo the change if problems arise.
By Mike Preston
VM compatibility mode plays a key role in how adaptable and mobile VMs can be in the data center. With every new release of vSphere, administrators have grown used to upgrading the virtual hardware in our VMs.
Clicking Upgrade VM Compatibility in the vSphere Web Client — or Upgrade VM Hardware in the desktop client — is yet another step in a vSphere upgrade that seems to be getting a little more complex with each release. What are we upgrading when we change the VM compatibility mode? Is it simply a compatibility matrix between the VM and ESXi or does it dictate what features are available to us? To answer these questions, let’s look at the history of the VM compatibility mode,
What is virtual hardware/VM compatibility mode?
First, we’ll use VMware’s preferred term of “VM compatibility” rather than “virtual hardware.” This makes a lot more sense when we look at what exactly VM compatibility is.
At its most basic, VM compatibility is just a version number that reflects which supported hardware features inside of ESXi that are available to a given VM. Features such as the maximum number of allowed CPUs, maximum memory configuration, and available PCI slots are all related to the VM compatibility version.
Since these features are mostly related to the version of ESXi running on the hosts, the VM compatibility mode also dictates on which hosts a VM can — and can’t — run. For example, a VM with a compatibility mode of ESXi 5.5 will have no problem running on an ESXi 5.5 host, but it will not be able to run on an ESXi 5.0 host.
The reverse is possible — to an extent. A VM with a compatibility mode of 5.0 will be able to run on an ESXi 5.5 host, just without the newer 5.5 maximums and features. Due to major changes within the hypervisor version, the supported VM compatibility versions do have a limit. The following table outlines VM compatibility support on the various ESXi versions.
| Compatibility | Hardware version | vSphere versions supported |
| ESXi 5.5 and later | 10 | ESXi 5.5 and later |
| ESXi 5.1 and later | 9 | ESXi 5.1 and later |
| ESXi 5.0 and later | 8 | ESXi 5.0 and later |
| ESX/ESXi 4.0 and later | 7 | ESX/ESXi 4.0, ESX/ESXi 4.1, ESXi 5.0 and later |
| ESX/ESXi 3.5 and later | 4 | ESX/ESXi 3.5,ESX/ESXi 4.0, ESX/ESXi 4.1, ESXi 5.1, ESXi 5.5. ESXi 5.0 may run VMs which are already created with ESXi 3.5, but will not allow the creation of new VMs with a compatibility version of ESXi 3.5 |
| ESX Server 2.0 and later | 3 | ESX Server 2.0, ESX/ESXi 3.5, ESX/ESXi 4.0, ESX/ESXi 4.1 and ESXi 5.0 |
Upgrading VM compatibility
Administrators must upgrade the VM compatibility mode to access the new hardware feature sets and supported configuration maximums in newer versions of ESXi. To execute this process, the only requirement is to power off the VM and make sure VMware Tools is updated before proceeding.
To upgrade, right-click the VM, select All vCenter Actions>Compatibility>Upgrade VM Compatibility. Once you confirm the upgrade and the compatibility mode, a task will spawn to perform the upgrade.
The option to schedule a VM compatibility upgrade is also available. This will flag the VM’s compatibility mode to be upgraded upon the next reboot of the VM. This allows us to schedule a reboot and have the compatibility upgraded at a more convenient time rather than having to power off the VM immediately.
Take precautions in case something goes wrong during — or after — the upgrade process. Since a vSphere snapshot will also capture the virtual hardware configuration of the VM, I often see administrators take temporary snapshots as a safeguard. This is a great solution, but be sure to go back and delete the snapshot.
Downgrading VM compatibility
As can happen in IT, there may come a time where we find ourselves in a predicament. For example, what if we had a VM at a compatibility level of 5.5 but we need to run it on a host running 5.0? We didn’t perform a backup, and we didn’t perform a snapshot. The only option is to downgrade the compatibility level.
Unfortunately, there is no simple downgrade option. Administrators can’t simply right-click the VM and perform a downgrade. In fact, no automated process of a downgrade even exists. That said, there are a few ways to perform a downgrade.
1. Using vCenter Converter: We have all used vCenter Converter to perform our physical-to-virtual (P2V) migrations in the past, but we can also use this to perform virtual-to-virtual (V2V) migrations. What we may not have noticed is that during the process we have the ability to set the VMs compatibility level during the conversion process — called virtual machine version in Converter. Utilizing Converter makes it possible to V2V a source machine with a compatibility level of ESXi 5.0 to a target machine with a compatibility level of 4.0.
2. Create a new VM: Another possible way to achieve a downgrade is to create a new VM with a lower compatibility level and attach the disks from the current VM to the new VM. The New Virtual Machine creation wizard features an option to select a lower compatibility version. Once the VM has been created, add the existing disks and point it to the old VMDK files to match them up with the old VM.
3. The unsupported VMX hack:
I would certainly recommend either reverting to a snapshot or trying methods 1 and 2 before resulting to this. That said, there is a way to downgrade a VM compatibility mode by simply editing the VM’s VMX file located in the data store where the VM resides. To do so, power off the VM and utilize the Vi text editor to change the virtualHW.version = “10” line to the desired hardware version listed in the table above. After the file has been saved, remove and re-add the VM to your inventory and power it on.
Setting the default compatibility version for new VMs
When different versions of ESXi are running the same VMs, administrators may need to change the default VM compatibility mode that is set when a VM is created. For example, if we had an environment consisting of both ESXi 5.5 and ESXi 5.1 hosts, we may want to change our default compatibility version to ESXi 5.1 and allow these new VMs to run on and migrate to both the 5.5 and 5.1 hosts.
The default VM compatibility can be set on the host, cluster or data center. To do so, right-click either your host, cluster, or data center object and select All vCenter Actions->Edit Default VM Compatibility.
Select the compatibility mode you prefer. If you have set a default compatibility mode on all three objects, the lowest object in the hierarchy will take precedence, meaning a host’s setting will override a cluster’s setting, which overrides the data center’s setting.
VM compatibility recommendations
I’ve always recommended that administrators pick an ESXi version and stick to it, making it consistent among all hosts in the data center. Ensure the compatibility mode is also is at the highest it can go without going to the point where a downgrade is required. This allows us to get the latest configuration maximums and latest hardware features of our hypervisor into our VMs, ensuring we get the most out of our virtualization investments.
