VMware CPU licensing metric change: What you need to know

Software publishers

VMware CPU licensing metric change: What you need to know

13 February 2020

7 minute read

This article was contributed by Barry Pilling, Managing Partner at Cortex Consulting.

In early February 2020, VMware announced a significant change to its long-serving CPU licence metric. This could have far-reaching consequences across all manner of enterprise IT estates, regardless of how you choose to deploy your infrastructure. VMware is, far and away, still the leading virtualisation platform on the planet so, even if you make use of hosted datacentres, chances are you’ll be impacted by the change in some way. To ensure we’re starting on firm ground, let’s examine the definition of the VMware CPU licensing metric as it stands.

VMware CPU Metric

CPU Metric

According to the current Product Guide (Dec 2019, at the time of writing):
‘“Processor” means a single, physical chip that houses a central processing unit that can execute computer programs.’

Simply put, for every physical CPU in a server where you are running the software, you are required to purchase a licence.

VMware has never previously worried about the number of cores in each CPU but that is about to change. From 2nd April 2020, VMware will be restricting each licence to cover only up to 32 cores per physical CPU. If the processors on which you’re running the software have fewer than 32 cores, nothing changes. If they have greater than 32, you’ll need an extra licence for the next 32 and additional licences for every subsequent block of 32. The latter scenario shouldn’t happen just yet, given that Intel and AMD are “only” manufacturing chips with up to 64 cores at the moment, but it probably won’t be too long before we’re talking about 96 or even 128 core CPUs.

VMware has couched it in terms that suggest it wants to help customers in an ever evolving industry but, in reality, this is just an attempt to increase revenues as the processor market trends towards ever greater numbers of cores in single CPU chips. It may well be the first step towards VMware introducing full-on core licensing.; VMware is the last of the big vendors to maintain a processor metric that only ever equates to socket CPUs. Most others switched to core licensing long ago, despite using terms like “CPU” and “processor” to describe them.

How does this affect me?

VMware, like Microsoft before, is making allowances for customers who may stand to lose out from the increased licence requirement. If you are already running your VMware estate on CPU hardware with over 32 cores per chip, or are planning to soon, you will be able to apply, through your reseller or directly to VMware, for additional free licences. There are, not surprisingly, conditions to applying:

The application must be made before 29th January 2021
Qualifying servers and the underlying CPU licences must have been purchased before 30th April 2020. Customers will be expected to prove this when applying for the additional licences
Customers must have active SNS (Support and Subscription) on the original licences at the time they make the application
Customers will be charged for standard support for the additional free licences when the SNS renews on the original licences

Contractual Enforcement

Let’s look at VMware’s contracts more closely. As you’d expect with any major vendor, there are a number of contracts in play. At the lowest level, there is the Product Guide; a product-specific set of terms which are published monthly. It is this document that contains the contractual definition of a licence metric and in which we can expect to see the updated CPU definition, probably in the April document. Sitting above this is the standard VMware EULA. One of the key clauses in this contract describes which Product Guide applies to your use of the licences you have bought. Short version – it’s the one that was in force when you bought them, e.g. if you bought some CPU-based licences in December 2019, your use is governed by the terms in the Product Guide for that month.

Catch me if you can

Given those facts, you may have a tendency to think that an updated metric won’t apply to you because you bought the licences before it came into force and, therefore, you are bound to a contractual definition that doesn’t include a licence restriction to 32-core CPUs. Unfortunately, you would be wrong; it will catch you eventually. If you have SNS on your licences, granting you upgrade rights, you will, at some point, install a new major, minor or maintenance release of the software. Once you install any new release of the software (even if it’s just a bug fix under a maintenance release) you then become bound to the terms of a new Product Guide – whichever one is in force when you install the upgrade. If that happens to be after April 2020, then you’ll suddenly fall within scope of VMware’s new CPU definition.

Upgrades

You can’t escape by refusing to upgrade either. The lack of an upgrade, you may think, precludes you from falling foul of the new Product Guide terms that would take effect. You would be correct in that understanding; however, a problem arises with VMware’s tendency to operate aggressive support lifecycles in their product base. Products like vSphere, which are subject to the enterprise infrastructure lifecycle policy and benefit from the longest lifecycle, still only receive 5 years of general support. If you want extended support after that, you have to prove to VMware that you have a plan to upgrade to the next supported version which, again, would put you within scope of the new CPU definition. If you don’t have SNS and, therefore, can’t upgrade without buying new licences, you will remain perpetually exempt from the changed CPU definition…at least, on paper. There will obviously come a time when you will have to upgrade because the risk of not doing so is a significant one to carry for business-critical infrastructure.

ELA

I’ll save the final word for the exalted VMware ELA (Enterprise Licence Agreement). If, like the vast majority of global VMware customers, you have an ELA, you will hopefully know that the standard EULA, and by extension the Product Guide, is incorporated into the ELA contract. In theory, you could avoid the additional licence requirement by not applying any new releases to your install base after April 2nd for the rest of the duration of your ELA. But what happens when you renew the agreement? You guessed it – you will be subject to a new set of terms, which will include the new CPU definition.

Next Steps

The important thing to do now is take a deep dive into your VMware estate to understand the impact. What does the underlying infrastructure look like now? What future expansion plans do you have? If you’re planning to deploy servers with >32-core CPUs at some future unspecified time, is it worth bringing the purchase forward so you can benefit from the additional free licences? Do you have the forewarning of hardware plans to even make that decision? There is not a great deal of time to act, so my advice would be to do it now before it’s too late.

VMware CPU licensing metric change: What you need to know