The Virtual Machine Is Using A Hardware Version

[Francesca Cruiz]

This article guides you through the process of determining if your virtual machine's hardware version is the most up to date for the VMware product that you are using. This resource also explains why a virtual machine created with one product may not power on from another product.

If you are experiencing a problem related to a virtual machine's hardware version, the information in this article may resolve the issue.

For information specific to:

To upgrade the virtual hardware:

Note: For Lab Manager virtual machines, they must be undeployed, have their virtual hardware version upgraded from their configuration, then redeployed.

Reactivation of a Windows guest operating system is not needed after upgrading the virtual hardware version. Update the VMware Tools version on the virtual machine for better performance, if prompted.

For information on virtual hardware versions and limitations, see Virtual machine memory limits and hardware versions (1014006).

Virtual machine hardware version compatibility for Fusion

I believe VMware recommends not upgrading HW versions so that there is not conflicts or issues when a VM is used between different product platforms such as ESXi, Fusion, Workstation, etc. Different products have different maximum levels of HW version support.

The recommendation from VMware is to only upgrade the virtual hardware version if new features are needed. This is because upgrading the virtual hardware version can be the equivalent of swapping out the drive of one system and placing it into a new one, which can cause compatibility issues if the guest operating system is not resilient in the face of hardware changes.

While upgrading the hardware compatibility along with other components during a major version upgrade is a common practice, it is important to consider whether new features are actually needed before doing so. If there are no new features that require the hardware upgrade, it may be best to leave the virtual hardware version as is to avoid any potential compatibility issues.

At the beginning of the year we performed an upgrade of our vSphere environment from vSphere 5.0 to vSphere 5.1 U1 Build 1063329 compromised of about a dozen ESXi hosts and a vCenter instance hosted on Windows Server 2008 R2 SP1. One of the outstanding issues from this project is the upgrade of Virtual Hardware for Virtual Machines.

I'm having trouble understanding why I should go to work and downtime to upgrade the Virtual Hardware version on all of our VMs. Our newly created Virtual Machines are using Virtual Hardware v. 9, the most recent supported version in vSphere 5.1 U1 which resolves issues we were having with Windows Server 2012 R2 and WinPE 4.0 on our older vSphere 5.0 instance. All of our older Virtual Machines are compatible Virtual Hardware versions (KB2007240) so we are not forced to upgrade their hardware version.

Am I missing some technical reason for upgrading all our Virtual Machine's Virtual Hardware to the "newest" Version 9 since guest operating system and ESXi compatibility are not issues? Upgrading the Virtual Hardware is not necessarily trivial since I have to shutdown the VM, take a snapshot or backup of it and then upgrade it for a few hundred VMs. Other than avoiding having to do this in the future and getting warm fuzzies that all our VMs are running on the most recent Virtual Hardware version why should I bother doing a straight cutover instead of a rolling upgrade as we replace our Virtual Machines?

Don't worry about this for the revision of vSphere you're on now. You can run all day on old versions, based on the setup you have. VM hardware version 8 sounds like the best choice for your specific situation.

The only real consideration with regard to virtual hardware versions is the move from version 8 or vmx-09 to the vmx-10 introduced in vSphere 5.5. There are manageability implications of this move. But on the positive, that process is streamlined through the vSphere Web Client, which allows you schedule the VM version upgrade during guest reboot.

This article guides you through the process of determining whether the hardware version of your virtual machine is up-to-date for the version of VMware Fusion that you are using. This resource also explains why a virtual machine created with VMware Fusion may not power on in another version/copy of VMware Fusion.

VMware Fusion powers on a virtual machine with a virtual hardware version that is lower than what it supports, but functionality may be lost. With lost functionality, menu items/settings related to virtual machine operations gray out and become unavailable.

Note: If a virtual machine is created in a different VMware product (for example, VMware Workstation) that supports a virtual hardware version, and it is then migrated to a version of VMware Fusion that does not support this level of virtual hardware, it does not power on. For example, Fusion 1.x does not power on virtual machines created in Workstation 6.x or 7.x. For information on virtual hardware versions for other VMware products, see Virtual machine hardware versions (1003746).

To upgrade the virtual hardware:

I recently switched from legacy mode to panorama mode. I had no issues during this process. However, ever since then, our backup software seems to crash Panorama. Panorama becomes unreachable and a reboot is necessary to resolve.

For upgrading the VM Panorama, you would need to have a valid maintenance contract, and go through getting the latest Dynamic Updates, and then upgrade from 7.x to 8.0 (reboot), from 8.0 to 8.1, then to 9.0, then 9.1, with reboots after every major version.

@SCantwell_IM sorry for the confusion. My Panorama is actually running 9.0.12. I switched to panorama mode from legacy, because I'm planning to upgrade to 10.x. It was my understanding that legacy mode was not supported in 9.1(+above). Palo documentation states they do not recommend legacy mode.

I'm running the Panorama VM on esxi 6.7, but the virtual machine hardware version is 7 (vmx-07). This is from when it was originally deployed. The problem is VM hardware vmx-07 has a max CPU of 8. What I'm not clear on is if I can upgrade the hardware version of the VM to vmx-10. If I can't increase the hardware version, then I can't increase the CPU.

As you stated, one option is to deploy a new OVA and restore config. The issue I have with that is, it seems like this would be something that have to continue to happen, as years go by. As I'm sure you are aware, every time you do this, you lose all your logs. Seems like there should be an easier way

The purpose of our article is to provide a comprehensive VMware hardware version overview. By way of background, VMware is an unquestionable leader in the market of cloud computing and virtualization, with the product line rich enough to suit the needs of virtually all businesses. So far, the company has released more than 10 virtual hardware versions.

Virtual hardware includes BIOS and Extensible Firmware Interface (EFI), while its version determines the amount of virtual PCI slots, maximum number of virtual cores, maximum memory size, and other characteristics typical for a physical machine. As an example, the maximum memory size in ESXi 6.0 (hardware version 11) is 4,080 GB, while in ESXi 6.5 (hardware version 13), it is as much as 6,128 GB.

A VMware product is unable to power on a VM if its hardware version is higher than this product supports. For example, VMware Fusion 6.x (VMware hypervisor for Macintosh) can only run a VM on a VMware hardware version 10 or lower. In order to run a VM on hardware version 11, you need VMware Fusion 7.x.

A quick reference: VMware ESXi is an enterprise-grade hypervisor designed for creating, running, and serving virtual machines. It is designed for bare-metal installation, meaning that it does not rely on an operating system, which allows for higher security and reliability.

If you are creating a new VM or upgrading an existing one, pay attention to the VM compatibility settings: you need to properly select the ESXi host version that the VM can run on. Precisely put, the compatibility settings determine the virtual hardware functions that are available to a VM. Each compatibility level of virtual hardware supports several vSphere releases. For example, a VM running on ESXi 5.5 can also run on ESXi 6.0, and ESXi 6.5.

As noted above, upgrading a VM to the latest hardware version may lead to further challenges. Therefore, the process requires careful planning and preparation. Consider performing the following steps before you get started:

Consider using a reliable data protection solution, such as NAKIVO Backup & Replication that enables backup and replication, automation features, and disaster recovery orchestration.

1 Year of Free Data Protection: NAKIVO Backup & Replication

NAKIVO website uses cookies for the purposes of analytics and to ensure the best browsing experience for the website visitors in accordance with our cookie policy.

You can reject cookies at any time in your browser settings.

A VMware Virtual Machine hardware version refers to the configuration of virtual hardware components and features that are available to a virtual machine running on the hypervisor. Each version of VM hardware provides a set of features and capabilities that can be utilized by the virtual machine, including vCPU, memory, network adapters, and storage controllers.

VMware releases new virtual hardware versions with each generation of its virtualization products. To ensure compatibility between a virtual machine and the platform, make sure to choose the appropriate hardware version for the virtual machine. Some VM hardware versions come with performance enhancements so updating them regularly can help to improve performance.

VMware virtual hardware version 20 in vSphere 8 unlocks some nice new features but also brings some completely new features to Virtual machines (VMs) in vSphere 8. As you know from the past, each release of vSphere allows bigger VMs, greater VMs per host density or greater overall scalability in management via vCenter server. The vSphere 8.0 is no different and VMware has maximized this version so much that they even had a hard time to find a hardware for testing those maximized specs.

3a8082e126