WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple
You are here: Home / Automation / How to limit the maximum supported VM Virtual Hardware/Compatibility in vSphere?

How to limit the maximum supported VM Virtual Hardware/Compatibility in vSphere?

07.02.2022 by William Lam // 1 Comment

In the vSphere UI, customers have had the ability to specify the default VM Compatibility (formally known as Virtual Hardware Version) for some time now when creating a new VM by right clicking on either a vSphere Datacenter or Cluster object to set the default VM Compatibility.


However, this is simply just configures the default VM Compatibility and automatically fills in this value both from the UI/API standpoint but it does not actually prevent users from selecting another supported VM Compatibility.

While browsing the VMTN Community, I saw a question that asked if it was possible to limit the maximum supported VM Compatibility?

Prior to vSphere 7.0 Update 2, this was actually not possible but now a new vSphere API property has been introduced called maximumHardwareVersionKey which will allow a customer to set the maximum supported VM Compatibility for a specific vSphere Cluster and  prevent users from creating a VM that is greater than what has been configured. To change this property, you will need to use the ReconfigureComputeResource_Task() API method.

Below is a summary of the current VM Compatibility to version key mapping that is needed to use this vSphere API.

  • vmx-4 - ESXi 3.5 or later
  • vmx-7 - ESXi 4.0 or later
  • vmx-8 - ESXi 5.0 or later
  • vmx-9 - ESXi 5.1 or later
  • vmx-10 - ESXi 5.5 or later
  • vmx-11 - ESXi 6.0 or later
  • vmx-12 - Workstation 12 or later
  • vmx-13 - ESXi 6.5 or later
  • vmx-14 - ESXi 6.7 or later
  • vmx-15 - ESXi 6.7 Update 2 or later
  • vmx-16 - Workstation 15 or later
  • vmx-17 - ESXi 7.0 or later
  • vmx-18 - ESXi 7.0 Update 1 or later
  • vmx-19 - ESXi 7.0 Update 2 or later

To demonstrate how this vSphere API works, I will using PowerCLI but you can also use any supported vSphere SDK that you are comfortable with as the example is applicable to them all. The input required by a user is the name of the vSphere Cluster and the VM Compatibility version string. In my example, my vSphere Cluster is called Supermicro-Cluster and I am using vmx-15 version to align with the original VMTN question.

$cluster = Get-Cluster Supermicro-Cluster

$spec = New-Object VMware.Vim.ComputeResourceConfigSpec

$spec.MaximumHardwareVersionKey = "vmx-15"

$cluster.ExtensionData.ReconfigureComputeResource_Task($spec,$true)


Once the vSphere Cluster has been reconfigured, you can use the vSphere UI to create a new VM and when selecting the VM Compatibility, you should now notice the maximum supported VM Compatibility has been limited based on the configured value. In my example, I have vCenter Server running 7.0 Update 3e but as you can see from the screenshot, I can not create a VM that has VM Compatibility that is greater than ESXi 6.7 Update 2 or later.


If you wish to restore the original default VM Compatibility behavior, simply set the maximumHardwareVersionKey property to $null or the equivalent and reconfigure the vSphere Cluster.

More from my site

  • Erasing existing disk partitions now available in the vSphere Web Client (vSphere 6.0 Update 1)
  • How to relocate an existing vSphere Content Library from one vSphere Datastore to another?
  • ESXi on Arm Fling is LIVE!
  • How to Netboot install ESXi onto Apple Mac Hardware?
  • How to bootstrap vCenter Server onto a single VSAN node Part 2?

Categories // Automation, vSphere

Comments

  1. *protectedDag Kvello says

    07/07/2022 at 3:54 am

    So all I need now is a "minimumHardwareVersionKey" (so that all new VMs, no matter how the come to be created are at a minimum vmx-19) and the ability to globally override "Defaults" when creating new VM's. Like, When someone creates a new "Windows VM" I wan't it always to use pvscsi, vmxnet3 and UEFI++.
    But, I've never found out where all the "Virtual HW defaults for OS x" is stored or how to change it to my preferences.
    Plenty of VMware appliances (including VCSA) use "LSI SCSI" and "E1000E" instead of PVSCSI and VMXNET3 and to many use vmx-10 or older when deploying.

    I'm suspecting a lot of "least common denominator" laziness from the developers, but it annoys me to no end.

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF 9.0 Single Sign-On (SSO) with Keycloak IdP 06/23/2025
  • Is my NIC supported with Enhanced Data Path (EDP) with VCF 9.0 06/23/2025
  • PowerCLI remediation script for running NSX Edge on AMD Ryzen for VCF 9.0 06/20/2025
  • Failed to locate kickstart on Nested ESXi VM CD-ROM in VCF 9.0 06/20/2025
  • NVMe Tiering with Nested Virtualization in VCF 9.0 06/20/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...