WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • 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

  • Quick Tip - vmware-iso builder for Packer now supported with ESXi 7.0
  • Automating the creation of NSX-T "Disconnected" Segments for DR testing on VMware Cloud on AWS 
  • Quick Tip - Retrieving vSAN File Share Network Permissions using vSAN API & PowerCLI
  • No suitable disk was found when upgrading to ESXi 6.5 on USB?
  • Good Gigs Trek: Cambodia Week 1

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

Leave a Reply to Dag KvelloCancel 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

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/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...