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.
Dag Kvello says
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.