Virtualisation | Cloud | Strategy

Extending – Counting CPU licenses needed under new VMware licensing policy

Following on from the VMware licence change announcements, detailed here.  I thought I’d take a quick look at the accompanying PowerShell module to see what the output looks like and what we can do with data that it gathers.

The VMware KB for the PowerShell module includes details on how to import and usage.  You may however come across an error when you try and import the module due to digital signatures, much like the image below;

if you encounter this then you can work around it by changing the execution policy for your PowerShell session, which can be used using the snippet below;

Note: An unrestricted execution policy loads all configuration files and runs all scripts. You’re prompted for permission before it runs. But is is against best practice, fine perhaps for the lab, but you might want to review before making this change in live.  Don’t take my word for it, follow the advice of @vBrianGraf!

Many of the organisations that I work with have multiple virtual centres that are not linked or sharing an SSO domain, so one of the first things I checked was if the PS successfully runs when the client is connected to multiple virtual centres.

As you can see from the image, output is certainly generated from 2 VCs.  In the image you can see that I’m connected to both a local VC in my lab and also a VMConAWS VC.

Exporting the PS generated table above to *.csv is very straightforward as it’s been included in the function

From the exported data all that we are really interested in is if there is a discrepancy in the licences required for the future VMware core based licensing model.  Ideally if we can get a nice simple visualisation that flags the impacted inventory items and highlights what actions need to be taken.

The data that we extract is clean, and only needs minimal tidying up.  After clean up we’re going to add in two columns to the data a conditional column that will check to see if the CPU_LICENCE_COUNT and CORE_LIMITED_CPU_LICENCE_COUNT match and if they do, then return that no uplift would be required, if they don’t match then an uplift will be required.  The second column we’re going to add performs a simple calculation to see what uplift (if any) is required.

You can see from above the steps that I’ve taken to clean the data and add the two additional columns.

With the first column we’ve added a conditional column, this will check through the data in the sequence we request and return values based on the detailed logic.  To call it out as a single line;

As mentioned above this is checking to see if values match, if they do it returns ‘no’, if they don’t it return ‘yes’ and if it cannot satisfy either argument it returns ‘err’.

The second column is adding the results of a simple subtraction;

As I’m sure you can follow above, it’s the result of the subtraction of the CORE_LIMITED_CPU_LICENCE_COUNT value and CPU_LICENCE_COUNT, which will provide us with the number of additional licences required.

Once we have our raw data we can create a simple dashboard.  Ive created the one below to highlight what percentage of the estate needs an uplift, how many new licences are required in total, which hosts require those licences, how many they need and I’ve included a table of the raw information;


Very simple to build, and I think it helps to pinpoint exactly what will be required following the announcement.

Note:  I connected to a VMC VC to create the data for this report and you can see that the report flags that the VMC hosts will require a licence uplift. However,  As VMC is a service that includes all VMware licensing, no uplift will be required for VMC hosts!