Sometimes, you’ll find yourself needing to downgrade the hardware version of a VM just so you can move it off a newer release of ESXi to an older one. Upgrading a VM’s hardware compatibility is as simple as right-clicking on it and choosing the option, but the converse is just not the case. The latter is reinforced by the warning shown in Figure 1.

Figure 1 - Upgrading the hardware or compatibility of a VM

Figure 1 – Upgrading the hardware or compatibility of a VM

 

As is often the case, a fix of sorts, supported or not, is thankfully lurking around the corner. A quick google search led me to this KB article which explains how to downgrade the hardware version.

 

Hardware Version Upgrade


Allow me to first cover what it is exactly that goes on when you upgrade the virtual hardware. Upgrading ESXi to a later version opens the door to a number of new or improved features all of which can be leveraged by VMs once their compatibility or hardware level is upgraded to the latest. Some of the features may include an increase in the computing resources you can allocate to a VM or perhaps added support for new hardware. One such example is the support added for NVMe in vSphere 6.5.

Figure 2, lists the existing hardware versions as per VMware’s documentation. The last entry shown in red is in fact the aforementioned NVMe support.

Figure 2 - Existing VM hardware versions, supported features and limits

Figure 2 – Existing VM hardware versions, supported features and limits

 

A newly created VM will by default use the latest hardware version unless otherwise specified (Fig. 3).

Figure 3 - Specifying the hardware version when creating a new VM

Figure 3 – Specifying the hardware version when creating a new VM

 

If, on the other hand, you upgraded an ESXi host with VMs on it, all must be upgraded manually or via a scheduled task. Although recommended, upgrading a VM’s hardware version is not mandatory. Having said that, make sure to plan accordingly. Why, you ask? For instance, if your environment has a mix of ESXi versions, one thing to keep in mind is the inability to migrate VMs to an ESXi box that does not support a specific hardware version. Pretty much, this was my issue when trying to migrate a VM with hardware version 13 over to an ESX 5.5 host. The latter supports hardware version 10 at best.

When a VM hardware upgrade to the latest is carried out, the VM is made fully compatible with the ESXi version it is running on. According to VMware’s documentation, each compatibility level will support at least 5 major and/or minor vSphere releases.

Looking at Figure 4, for instance, you’ll see how version 7 introduced with ESXi 4, is still supported four vSphere releases down the line. The converse is however false meaning that the highest hardware version is supported only on the ESXi version implementing it.

Note: ESXi 6.5, being the latest release, implements hardware version 13 (not shown in Fig. 4).

Figure 4 - ESXi supported VM hardware versions

Figure 4 – ESXi supported VM hardware versions

 

Upgrading VM Hardware


To upgrade the hardware version, you would simply select a VM, right-click on it and select Upgrade VM compatibility. That’s all there is to it.

Figure 5 - Upgrading VM hardware in vSphere Web client

Figure 5 – Upgrading VM hardware in vSphere Web client

 

As mentioned, you can schedule the task when you have a bunch of VMs to upgrade for instance. There are some limitations to scheduling in that you cannot set the day or time, so it’s not really true scheduling. Instead, the upgrade occurs once a VM is rebooted or the guest OS is shut down. Scheduled upgrades may be cancelled using the same context menu as per Fig. 5 – Cancel Scheduled VM Upgrade. Regardless of the method, you must choose a compatibility level as shown in Fig. 6.

Figure 6 - Scheduling a VM hardware upgrade from vSphere Web client

Figure 6 – Scheduling a VM hardware upgrade from vSphere Web client

 

The same can be performed with PowerCLI. Here’s how.

  • To check the hardware version of a VM, use the following:
(get-vm -name "myVM").Version

 

  • To upgrade the hardware version, use the Set-VM cmdlet as follows.
$vmToUpgrade = Get-VM -name myVM
Set-VM -VM $vmToUpgrade -Version v10 -Confirm:$false

If the version supplied is not supported by the ESXi host, the cmdlet will throw an “operation is not supported on the object” error as shown next.

 

  • To schedule the hardware upgrade, use the following. Note that the string format for the hardware version is vmx-n and not vn unlike the format expected by Set-VM.
$vmSpec = New-Object -TypeName VMware.Vim.VirtualMachineConfigSpec
$vmSpec.ScheduledHardwareUpgradeInfo = New-Object -TypeName VMware.Vim.ScheduledHardwareUpgradeInfo
$vmSpec.ScheduledHardwareUpgradeInfo.UpgradePolicy = "always"
$vmSpec.ScheduledHardwareUpgradeInfo.VersionKey = "vmx-10"
$vmToUpgrade = Get-VM -Name MyVM
$vmToUpgrade.ExtensionData.ReconfigVM_Task($vmSpec)

The scheduled task is executed once the VM is rebooted which will upgrade the VM to the hardware version value specified.

 

Downgrading VM Hardware


Let’s go back to my problem. As mentioned, I needed to move a VM with hardware version 13 to an ESXi 5.5 host.

The easiest fix is to create a new VM with the same exact hardware specs, hard drives excluded. It is then just a matter of attaching the disks from the old VM to the new one. This method is actually supported by VMware. A slight inconvenience, in my case, is that the VM in question is running VCSA and sports no less than a dozen disks. Adding each and every one manually is a major pain, no two ways about it, but it works.

A second and perhaps less strenuous option is using VMware vCenter Converter which allows you to downgrade a VM’s hardware version while moving it across hosts. This is shown in Figure 7. An added bonus is that the original VM is left intact on the source host. Incidentally, I wrote a post on Converter, so if the product is somewhat new to you, make sure to give How to convert a Hyper-V VM to run on vSphere a quick look.

Figure 7 - Using the VMware vCenter Converter to downgrade the hardware version of a VM

Figure 7 – Using the VMware vCenter Converter to downgrade the hardware version of a VM

 

A third option is to revert to a snapshot taken before the VM hardware was actually upgraded. In my case, this was not an option so you might want to snapshot critical VMs before upgrading, just in case. That said, it is not good practice to retain snapshots for prolonged periods of time.

There in in fact a fourth and final, albeit VMware unsupported, option that warrants a slight modification to the VM’s VMX file. The procedure, which can be carried out via the vSphere Web Client, is this one.

1. Change to Datastore Browser view after you determine on which datastore – use the Summary tab – the VM’s disks reside.

2. Open the VM’s folder and highlight the VMX file (Fig. 8-1). Download the file by clicking on the Download icon (Fig.8-2). Rename the VMX file in case you need to revert back.

Figure 8 - Locating the VM's folder in Datastore Browser

Figure 8 – Locating the VM’s folder in Datastore Browser

 

3. Remove the VM from inventory by right-clicking on it and selecting Remove from Inventory.

Figure 9 - Removing a VM from inventory

Figure 9 – Removing a VM from inventory

 

4. Edit the downloaded VMX file using something like Notepad++. Find the line with the virtualHW.version value and change it accordingly. In Figure 10, I’ve changed the previous value of 10 to 8.

Figure 10 - Editing the VMX file ...

Figure 10 – Editing the VMX file …

 

4. Back in Datastore Browser, upload the modified VMX file by clicking on the Upload button. After uploading it, right-click on it and select Register VM. Provide the info requested by the Register Virtual Machine wizard and you’re done.

Figure 11 - Using the VMX file to register a VM

Figure 11 – Using the VMX file to register a VM

 

You should now be able to migrate the VM. Needless to say, this method should not be used on live systems unless you’re particularity desperate. I still need to test the case where a VM is configured with hardware not supported by earlier hardware versions. In short, use this method only as a last resort.

Update:  After finishing this post, I had to try out the unsupported use case, hence this. An easy test case is one where you create a VM with an NVMe controller and NVMe disk which is only supported on ESXi 6.5. The VM created is by default running at hardware version 13. Changing this, say,  to version 10 should prove to be pretty interesting. In fact and as expected, both the controller and disk end up being listed as unsupported once the VM is added back to the inventory after the hardware version has been downgraded. The result is that you will not be able to power it up before you delete the offending hardware or upgrade back to the the original hardware version!

Figure 12 - A pitfall to changing the hardware version using an unsupported method

Figure 12 – A pitfall to changing the hardware version using an unsupported method

 

Figure 13 - VM cannot be powered on when unsupported hardware is detected

Figure 13 – VM cannot be powered on when unsupported hardware is detected

 

Conclusion

We’ve seen how the VM hardware or compatibility version changes with every new version of ESXi released. Upgrading to the latest hardware version allows VMs to leverage newly released features and in some case boost performance across the board.

Once in a blue moon, you’ll find yourself needing to downgrade the hardware version of a VM. I’ve covered four possible ways on how to do this with three methods being fully endorsed by VMware and a fourth which is not.

[the_ad id=”4738″][the_ad id=”4796″]

Download Altaro VM Backup

Start your free 30-day trial of Altaro VM Backup today and see why it's trusted by 40 000+ organizations worldwide. Get started now and run your first backup in under 15 mins!

Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

Leave a comment

Your email address will not be published. Required fields are marked *

Related posts