Latest posts by Brandon Lee (see all)
- Importing PST files to Office 365 with LAE Software PST Migrator - Thu, Mar 26 2020
- AdRemSoftware WMI Tester: Testing WMI connectivity - Tue, Mar 24 2020
- VMware vSphere 7: New features - Thu, Mar 19 2020
With the recent news of VMware changing its licensing from per-CPU to per-core, organizations will need to take the core count into consideration when buying VMware licensing in the future. What about organizations that have hundreds or maybe thousands of ESXi hosts? This type of auditing will become difficult when done manually. Automation enables auditing the CPU core license count quickly and effectively. Let's take a look at performing a new VMware processor licensing audit with PowerShell.
PowerShell with VMware ^
Working with VMware with PowerShell is performed by means of PowerCLI, which is an installable module that can be pulled down and installed "online" from your PowerShell cmd prompt. Use the following:
This will install VMware PowerCLI on your client and allow you to work with VMware from a standpoint of PowerShell automation. Now that you have PowerCLI installed, you can take advantage of VMware's specific PowerCLI module, which is written for the purpose of auditing your environment for future licensing purposes. Let's see how.
VMware CPU licensing Audit PowerShell module ^
In short, the news released by VMware regarding the license change includes a move to define a VMware 1-CPU license as a CPU with up to 32 cores. As soon as you go over the 32-core count in a single physical CPU, you will need to purchase additional VMware CPU licenses to align with the new license model.
As a side note to the licensing audit, the new licensing takes effect on April 2, 2020 with a grace period for organizations purchasing new hardware that will extend until April 30, 2020. VMware will essentially give businesses "free" licensing for cores in addition to the new 32-core CPU license.
In conjunction with the news of the forthcoming licensing changes, VMware also released a PowerShell module that makes it much easier to query your VMware vSphere environment(s) for the CPU count, the number of licenses that are required now, and the number of licenses that will be required when the license changes go into effect.
Let's take a look at how use the new PowerCLI module to download and run a license audit to pull the relevant information for VMware licensing.
Audit VMware Licensing with the VMware PowerCLI Audit module ^
VMware's official KB article, "Counting CPU licenses needed under new VMware licensing policy (77098)," enables downloading the PowerShell module and provides instructions on its use. There are only a few steps involved in getting the new tool in place so you can use it effectively to audit your current vSphere license usage and plan for licensing after the change is in effect.
The steps involved with the new VMware processor licensing audit with PowerShell are:
- Download the PowerShell module for VMware PowerCLI.
- Connect to the vCenter Server.
- Import the PowerShell module.
- Run the Get-vSphereCPUSocketToCoreUsage
If you miss where the file is downloaded on the VMware KB, there is an Attachments box located in the right-hand column. Click the attachment link to download the file, which is a ZIP file containing the vSphereCPUSocketToCoreUsage.psm1 file. This is the module file that we will import into our PowerShell environment.
Let's take a look at importing the downloaded module into PowerShell and running the script to audit your VMware vSphere environment licensing. Here, we use Visual Studio Codes as the Code Editor interface with PowerShell. Below is a quick run-through of the steps to import the module into your PowerShell environment after downloading the module.
The cmdlet we run is the Get-vSphereCPUSocketToCoreUsage function. As you can see, we are simply importing the parent module from the extracted directory, connecting to vCenter Server, running the function, and receiving the output of the audit of our vSphere clusters.
***Note*** If you run the function without any parameters, it will iterate through your vSphere environment and audit ALL clusters and their respective CPU cores per socket and determine the future license requirements based on the cores that are physically installed.
- You can add the -Cluster parameter to explicitly audit a particular vSphere cluster for licensing purposes.
One thing to be aware of if you hit the VMware KB and downloaded the audit script as soon as it was posted: There was an updated version of the script that was posted shortly after the first version was available for download. The first version of the script either incorrectly "added" the number of sockets * cores or counted hyperthreads.
As you can see below, the first version of the function that I have stored in the vSphereCoreLicense folder reports the NUM_CPU_CORES_PER_SOCKET as 24. The particular CPUs installed in these servers are 12 core Intel processors. The returned value of 24 is not correct in terms of the "number of cores per socket."
The second version of the script was posted a couple of days later. I stored this version in the vSphereCoreLicense2 folder. Importing and running this version of the script correctly identifies the number of cores per socket as 12 cores. Be aware that if you have already downloaded and run the script early on, it is worth re-downloading the latest audit script available to ensure you have the correct results returned to you for audit purposes.
With the change in VMware licensing coming in only a couple of months, businesses need to start auditing their environments to determine their future license needs when the April 2, 2020 change is implemented. VMware customers with larger environments or even several vSphere clusters will benefit from automated licensing auditing.
VMware PowerCLI provides an easy way to do this with the provided VMware script via KB 77098. The steps to audit using the script are straightforward and only require that you import the module and run the included function in your environment after connecting to vCenter Server.