Today we have a special guest post from Mathieu Buisson:

In a vSphere environment, resource overcommitment can be a blessing and a curse. It is a blessing because it allows to run more VMs per host and to fully utilize the physical resources provided by the ESXi hosts, but it becomes a curse when too much overcommitment impacts performance of the VMs.

Checking the overcommitment levels on one host is easy, especially for CPU and memory resources, with esxtop, but what if you want to monitor these for several hosts?

For a DRS cluster, it may make more sense to monitor the overcommitment of CPU and memory resources at the cluster level. Also, for capacity planning purposes, you may want to measure this at the datacenter level, or for all hosts in your vCenter environment.

I wrote a PowerCLI module which makes this quick and easy. It contains 3 simple cmdlets: Get-CPUOvercommit, Get-MemoryOvercommit and Get-StorageOvercommit. It is the .psm1 file available here.

How to get started

It is a module, so you need to load it in your PowerCLI session, using the cmdlet Import-Module, to make the cmdlets it contains available.
Or, you could do like the cool kids: put the module file in a folder located in your PSModulePath environment variable and let Powershell 3.0 (or later) automatically load it for you.

Get-CPUOvercommit

This cmdlet obtains the number of vCPUs and the number of physical CPU cores for one or more ESXi hosts and compares them to evaluate CPU overcommitment.

It measures an overcommitment ratio and percentage by comparing the number of vCPUs of all the running VMs for a given host and the number of physical cores on that host.

For a DRS cluster, you may want to use the -Cluster parameter, which provides aggregate values for the specified cluster:

The values may not be very representative (it is just a tiny lab for illustration purposes) but the key here is the value of “vCPU/Core ratio”: lower than 1 means that there is no overcommitment and greater than 1 means that there is overcommitment.

The -VMHosts parameter of Get-CPUOvercommit takes pipeline input, so you can get exactly the hosts you are interested in, using Get-VMHost and then pipe them to Get-CPUOvercommit, and format the result as a table if you want:

Get-MemoryOvercommit

This cmdlet obtains the physical RAM of one or more ESXi hosts and the memory presented to the VMs on the host (also known as vRAM). The property named “Total vRAM (GB)” includes all the VMs registered to the host, whereas “PoweredOn vRAM (GB)” includes only the running VMs.

Again, the overcommitment ratio takes only into account the running VMs.

It can be run without any parameter. In this case, it checks every host managed by the vCenter server(s) PowerCLI is connected to.

Get-StorageOvercommit

Storage overcommitment is different from CPU and memory overcommitment in that it is more about capacity than performance. But still, it needs to be monitored because a host of bad things happens when a datastore is full.

This storage overcommitment is possible only when there are thin provisioned VMDKs and this doesn’t take into account thin provisioning at the LUN level, which may be provided by the storage array.

This cmdlet obtains the used space, provisioned space and capacity for one or more datastores (or a datastore cluster if the -Cluster parameter is used) and it compares the provisioned space with the capacity to measure storage overcommitment.
The provisioned space includes the space provisioned for all VMDKs, snapshots, linked clones, swap files and VM logs.

The -Datastore parameter takes pipeline input so, here is an example of selecting a specific set of datastores and piping them to Get-StorageOvercommit.

The 3 cmdlets of this module also have a -Quiet parameter. In “quiet mode”, they only output a boolean value: “True” if there is overcommitment, “False” if not.

This can be useful to trigger some actions depending on whether there is overcommitment or not, most likely in a PowerCLI script.

This is pretty much all there is to it, but in case you want a detailed documentation for these cmdlets, it is only a “Get-Help” away.

Hope it is useful!

Mathieu is a support engineer in the French TLS team, providing technical support on vSphere to customers in the French market. He joined VMware in late 2012 and as part of VMware Support, is committed to deliver a great support to customers with their ESXi and vCenter-related issues.

On his spare time, he likes listening to noisy music, cycling and learning new IT products and technologies. He is a fervent Powershell advocate and PowerCLI enthusiast.