Home > Blogs > VMware PowerCLI Blog


PowerCLI Module to Check CPU, Memory and Storage OverCommitment

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:

CPUOverCommit

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:

CPUOverCommit2

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.

MemOverCommit1

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

MemOverCommit2

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.

StorageOverCommit1

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.

StorageOverCommit2

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 Buisson

 

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.

This entry was posted in Learning, Performance, vCenter and tagged , , , , , , on by .
Brian Graf

About Brian Graf

Brian Graf is a well-known VMware evangelist in the IT community. Over the past 5 years, Brian has done Technical Marketing for PowerCLI Automation and ESXi Lifecycle, Product Management of vCenter Distributed Resource Management features (DRS & HA), and is currently working as a Technical Marketing Manager for VMware Cloud on AWS. Brian is a co-author of the PowerCLI Deep Dive 2nd edition book. He has helped develop VMware certification courses and exams and presents around the world at VMware User Conferences, AWS Summits, Interop, as well as other industry Conferences. Brian is also a Microsoft MVP.

11 thoughts on “PowerCLI Module to Check CPU, Memory and Storage OverCommitment

  1. Server System Engineer

    Hi Brian and Mathieu ,

    Thanks for sharing such a great script. However, it doesn’t work when I execute it under my PowerGUI console session as follows:

    Import-Module -Name “C:\Users\Administrator\Documents\WindowsPowerShell\Modules\Add-on.VMware-OverCommitment\Add-on.VMware-OverCommitmentScript.psm1”
    Get-CPUOvercommit -Cluster “Production”

    it returns with long error message:

    Unable to find type [ordered]: make sure that the assembly containing this type is loaded.
    At C:\Users\Administrator\Documents\WindowsPowerShell\Modules\Add-on.VMware-OverCommitment\Add-on.VMware-OverCommitmentScript.psm1:74 char:50
    + $OvercommitInfoProperties = [ordered] <<<< @{'ESXi Host'=$VMhost.Name
    + CategoryInfo : InvalidOperation: (ordered:String) [], RuntimeException
    + FullyQualifiedErrorId : TypeNotFound

    New-Object : Cannot validate argument on parameter 'Property'. The argument is null or empty. Supply an argument that is not null or empty and then try the command again.
    At C:\Users\Administrator\Documents\WindowsPowerShell\Modules\Add-on.VMware-OverCommitment\Add-on.VMware-OverCommitmentScript.psm1:83 char:73
    + $OvercommitInfoObj = New-Object -TypeName PSObject -Property <<<< $OvercommitInfoProperties
    + CategoryInfo : InvalidData: (:) [New-Object], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.NewObjectCommand

    Any idea of how to load the script properly ?

    Thanks

    Reply
    1. Mathieu Buisson

      [ordered] is to guarantee the order in a hash table and it is a new feature introduced in Powershell version 3.

      Can you check the value of $PSVersionTable.PSVersion to make sure this is using Powershell version 3 or later ?

      If yes, and if you encounter this issue only in PowerGUI, then it seems that PowerGUI is confused by the square brackets and tries to look for a .NET class called “Ordered”.
      This doesn’t work because [ordered] is not a .NET class but it is more like a hint for the Powershell interpreter.

      In this case, you might have to try a more recent version of PowerGUI or remove all the occurrences of “[ordered]” from the script.
      The only issue if [ordered] is removed from the script is that the order of the properties of the output object will not be guaranteed.
      This means you might get : ‘Total vCPUs’, ‘CPU Overcommit (%)’, ‘ESXi Host’, ‘CPU Cores’, and ‘PoweredOn vCPUs’ in this order, or any other order.

      Reply
  2. Pingback: vCoffee Links #12 – PEX, PowerCLI, EVALExperience, and more… » vHersey - VCDX Two to the Seventh Power (#128)

  3. Greg

    It would be great ito update this script so it can take Get-Cluster as a pipeline argument or work with “-Cluster *” parameter to show all cluster.

    Thanks,
    Greg

    Reply
    1. Mathieu Buisson

      Hi Greg,

      Great idea !

      Adding pipeline input for the -Cluster parameter and the ability to process more than one cluster makes a lot of sense.

      However, this forces the -Cluster parameter to take objects of the type VMware.VimAutomation.ViCore.Impl.V1.Inventory.ClusterImpl and removes the ability to give it a simple string, which some users might prefer…

      Anyway, I will work on that and add a reply to your to comment to let you know.

      Thanks.

      Reply
  4. Steve Huon

    1) Is there a command so I can have the CPU and MEMORY overcommit in one screen? So 1 table which lists me the host with all the CPU en MEM overcommit details?
    2) I have multiple ESX clusters, is there a way to add the cluster field to which the host belongs?

    Reply
  5. Sunny

    Please ignore my posting, found the issue .

    Sunny

    Reply
  6. dk

    very useful … Thank you!

    Reply
  7. Jorge

    These command lets are deprecated on PowerCli 6.3 R1 . Is there any replacement commands ?

    Reply
  8. Dennis Zimmer

    Thanks a lot for putting that powercli module together! I integrated that module also into our OpBot, so you can run it out of slack chat 🙂 Please send me an email if you want to test it yourself.

    Reply
  9. Paul

    This gave me wacky results – 3 identical Hosts each with 2 x Sockets with 6 cores each & HT = 24 vCPU
    When i ran this against those 3 to format-table it told me that they had 24, 36 & 48 vCPU respectively ??

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*