Planning a VM Hardware Version Upgrade in vSphere: When, How and What to Check

Direct answer: upgrade a VM's hardware version only when you need something the newer version provides. That might be a guest operating system that requires it, a device or limit it introduces, or CPU features needed to mitigate a security vulnerability. In practice it cannot be undone in place: ESXi has no downgrade, and the VM can no longer run on, or be vMotioned to, any host that does not support the new version. Before upgrading, confirm every host and vCenter that might run the VM (including DR and restore targets) supports the target version. Update VMware Tools first, take a backup or snapshot, and then upgrade with the VM powered off, either by hand or through a vSphere Lifecycle Manager task scheduled for a set date and time. Afterwards, check that the guest's network settings, devices and applications are intact.

Why it matters

Broadcom's own guidance on hardware versions (KB 315655) opens with a warning: upgrading is "not recommended unless features in the new version are needed". It also notes that an upgrade may be required for security compliance, to expose new CPU flags that mitigate known CPU vulnerabilities. The practical risks:

• Placement. "Virtual machines cannot be vmotioned to ESXi versions which do not support their vHW version." A VM upgraded to version 21 runs on ESXi 8.0 U2 and later, but no longer on 8.0 or 8.0 U1 hosts that may still exist in another cluster, a DR site or a restore target.
• Management. vCenter "will not be able to properly manage a virtual machine with a vHW version above what existed when it was released". The KB's example: hardware version 15 needs both hosts and vCenter at 6.7 U2 or later.
• No in-place rollback. The KB lists only Workstation, Converter and Fusion as able to downgrade a hardware version, and none of those is a vSphere operation. Rollback means reverting to a snapshot or restoring from backup.
• Guest changes. The guest sees a newer virtual chipset and devices. Most guests handle this, but Windows guests can re-detect network adapters (see Interpreting the results).

Equally, staying on an old version has costs: some guest operating systems and features are only available at newer versions, and an old version can leave symptoms that look like faults. KB 315655 lists greyed-out operations, unexpected guest behaviour, disks reported as hard disks rather than SSDs, and an EVC mode limited by the hardware version.

How it works

A hardware version, called VM compatibility in the vSphere Client, defines the virtual hardware platform the VM presents. That covers the chipset, device types, maximum CPUs and memory, and available features. It is separate from VMware Tools. Tools is software inside the guest; the hardware version is a setting of the VM's configuration (virtualHW.version in the .vmx file). The published Tools article covers the guest agent and what stops working when it is missing.

KB 315655 maps each version to the release that introduced it. Recent entries:

KB 312100 adds what each host release can do with each version. For example: - version 22 is Create/Edit/Run on ESX 9.0 and Not Supported on ESXi 8.0 U2/U3 or earlier; - version 21 is supported on ESX 9.0 and ESXi 8.0 U2/U3, but not on 8.0 or 8.0 U1.

Read the current table for the exact pairs in your estate rather than relying on this summary.

Two rules from KB 315655 decide most plans: - A product cannot power on a VM whose hardware version is higher than it supports. - A product can power on a VM with a lower version, with some functionality unavailable.

Older versions therefore keep running on new hosts, which is why upgrading is optional.

Ways to upgrade: - Manual, per VM. Power off, then choose Compatibility > Upgrade VM Compatibility in the vSphere Client. KB 315655's general sequence is: power on, install VMware Tools, power off, then upgrade the hardware. - vSphere Lifecycle Manager, one VM or many. "Upgrade VM Hardware to Match Host" can run on a VM, a cluster or other containers, immediately or at a specific date and time. It can schedule separately for powered-on, powered-off and suspended VMs. Under Rollback Options it can take a snapshot of each VM first (selected by default) and keep it for a fixed period or indefinitely.

Read-only checks

None of these was run for this article. They read inventory only.

1. Inventory current versions. In the vSphere Client, add the "Compatibility" column to a VM list. With PowerCLI (read-only):

Get-VM | Select-Object Name, PowerState, HardwareVersion, @{N='Host';E={$_.VMHost.Name}} | Sort-Object HardwareVersion | Format-Table -AutoSize

2. Inventory host and vCenter versions everywhere the VM might run. Include other clusters it might move to, DR or replication targets, and the hosts a backup product would restore to.

Get-VMHost | Select-Object Name, Version, Build, Parent | Sort-Object Version

The lowest host version in that set limits the highest hardware version you can use without losing placement options. Check vCenter's version as well (KB 315655 management note).

3. Check VMware Tools state for the candidate VMs. In the VM Summary or with Get-VM app01 | Select-Object Name, @{N='Tools';E={$_.ExtensionData.Guest.ToolsVersionStatus2}}. Upgrade Tools before the hardware (KB 315655 sequence).

4. Record the guest's network configuration. For Windows guests, record each adapter's name, MAC address and IP settings before the change (Get-NetAdapter and Get-NetIPConfiguration are read-only). For Linux guests, record interface names and their configuration files. This is what you compare afterwards.

5. Identify why the upgrade is wanted. Use the vSphere documentation "Hardware Features Available with Virtual Machine Compatibility Settings" (the older KB 318970 points there) and the guest OS compatibility guide. Name the feature, limit or guest support that requires the new version.

6. Check snapshots and backups. Confirm the VM has a recent backup, and whether it already has snapshots that would make a new one deepen an existing chain.

Interpreting the results

Decision guidance

Choose the target version deliberately. "Upgrade to latest" picks the newest the current host supports, which may exceed what other hosts in the estate support. In mixed estates, choose the version supported by every host that matters (check 2). Upgrade further only after the older hosts are gone.

Prepare: - Update VMware Tools and confirm it is running. - Take a backup, and decide whether you also want a snapshot for quick rollback. Lifecycle Manager can take one automatically; remove it once the VM is verified, because snapshots left in place grow and slow consolidation. - Schedule a maintenance window that covers the power-off, the upgrade and the first boot.

Upgrade: - Manually: power off the VM, upgrade compatibility, power on. - With Lifecycle Manager: use "Upgrade VM Hardware to Match Host" with the snapshot rollback option, run immediately or scheduled for a date and time inside the window.

Verification after the first boot: - The guest boots and VMware Tools reports running. - Windows: compare adapters and IP settings with the record. If an adapter was re-detected, the static settings may sit on a hidden, non-present adapter; the published static IP article covers diagnosis. KB 315655 states that reactivating Windows is not needed after a hardware version upgrade. - Linux: check interface names and that services bound to them started. - Applications respond, and backup and monitoring jobs complete on their next run. - The VM's compatibility shows the intended version.

Rollback: - If you kept a snapshot, revert to it. This discards guest changes since the snapshot, so revert promptly if the problem is immediate. - Otherwise restore from the backup taken before the change, using a restore target that supports the old version. - There is no in-place downgrade in vSphere. After verification, remove the snapshot.

Templates. Upgrading a template changes every future VM. Rebuild or upgrade templates on the same rule: only to a version every target host supports. Validate the template afterwards (see the template article).

What not to do

• Do not bulk-upgrade every VM to the newest version because the client offers it.
• Do not upgrade VMs that may need to fail over or restore to older hosts until those hosts are upgraded.
• Do not edit virtualHW.version in a .vmx file by hand on ESXi. KB 315655 describes that only for VMware Player, and vSphere has supported upgrade paths.
• Do not leave the pre-upgrade snapshot in place indefinitely.
• Do not change other hardware (disk controller type, NIC type, firmware) in the same window. A disk controller change has its own boot risk, covered in the published article on that topic, and combining changes hides which one caused a problem.

Limitations

• Exact feature-to-version mappings, and host support tables for versions released after this article, must be read from current Broadcom documentation. Version 22 support on ESX 9.x releases should be checked in KB 312100 for the specific 9.x update.
• The vSphere Client also offers a per-VM scheduled compatibility upgrade. Its documentation could not be read in full for this article, so that option is not described here.
• Guest behaviour on new virtual hardware depends on the guest OS and drivers. Adapter re-detection on Windows is described as a risk to check, not as a certainty.
• No claim is made about what hardware versions any particular hosting service runs.

Acceptance checklist

• [ ] Reason for the upgrade named (feature, guest OS support or security mitigation)
• [ ] Every host, DR target and restore target supports the target version; vCenter is current enough
• [ ] Target version chosen deliberately (not "latest" by default)
• [ ] VMware Tools updated and running
• [ ] Guest network configuration recorded
• [ ] Backup taken; snapshot taken if wanted, with removal date
• [ ] Upgrade done powered off, by hand or as a scheduled Lifecycle Manager task
• [ ] Guest boots; Tools running; adapters and IP settings match the record; applications and jobs verified
• [ ] Snapshot removed after verification; templates handled on the same rule

References

All accessed 2 November 2026. Broadcom knowledge base articles do not display a last-updated date; TechDocs pages show "Last Updated October 28, 2026" where readable.

• Broadcom KB 315655, Virtual machine hardware versions: https://knowledge.broadcom.com/external/article/315655/virtual-machine-hardware-versions.html
• Broadcom KB 312100, ESXi hosts and compatible virtual machine hardware versions: https://knowledge.broadcom.com/external/article/312100/esxi-hosts-and-compatible-virtual-machin.html
• Broadcom TechDocs, vSphere 8.0, Upgrade the VM Hardware Compatibility of Virtual Machines (vSphere Lifecycle Manager): https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/managing-host-and-cluster-lifecycle/upgrading-virtual-machines-with-vsphere-lifecycle-manager/upgrading-virtual-machines/upgrade-vm-hardware-compatibility-of-virtual-machines-h5.html
• Broadcom KB 318970, Hardware features available with virtual machine compatibility settings (historical; points to current documentation): https://knowledge.broadcom.com/external/article/318970/hardware-features-available-with-virtual.html

Related articles

• VMware Tools Not Running or Out of Date: What It Breaks
• How to build and validate Windows Server templates for VMware
• VM Will Not Boot After a Disk Controller Change: Diagnosis

• Static IP Lost After a VM Restore or Virtual NIC Change

• vMotion fails: telling CPU compatibility, device dependencies and the vMotion network apart

• Adding a vTPM to a VMware VM: Key Provider Requirements and What Changes Afterwards
• Planning a vSphere Major Upgrade: Order, Interoperability and a Go/No-Go Record

Learning notes

1. The hardware version is the VM's virtual platform; VMware Tools is guest software. They are upgraded and rolled back differently.
2. Upgrading is effectively one-way in vSphere, and it limits the VM to hosts that support the new version, including DR and restore targets.
3. Broadcom recommends upgrading only when a feature or security mitigation needs it.
4. Order: Tools first, backup or snapshot, upgrade powered off (by hand or as a scheduled Lifecycle Manager task), then verify network, devices and applications.
5. Rollback is a snapshot revert or a restore, so plan it before the change and remove the snapshot after verification.