VMware CPU licensing metric change: What you need to know
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.
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.
Further Reading
VMware are still relevant – https://marketplace.itassetmanagement.net/2019/09/05/dont-let-cloud-adoption-fool-you-vmware-are-still-relevant/
Related articles:
About Barry Pilling
He is an expert SAM consultant who has worked with multiple clients across a huge range of industry sectors. He specialises in data centre and infrastructure licensing and processes across all platforms, and is a firm believer in simplifying software asset management.
He is a member of Working Group 21, which defines ITAM standards for ISO, a contributor to the Campaign for Clear Licensing, and can often be found trying to help people on the ITAM Review forum.
Connect with Barry on Twitter or LinkedIn.
Two points let me know your opinion.
1. As a point of principle, VMware cannot change your ELA terms without consent. The ELA grants you rights to new software releases during the life of the ELA. Even if you upgrade your software to versions released after the 30th of April 2020, the ELA contract takes precedence over new Product Guide terms that may accompany new versions. Hence one’s estate should not be seen as non-compliant at any stage before the ELA renewal due to not taking up additional licenses to cover the 32-cores sockets. Fully accept that one would have to cede to the new terms at renewal.
2. Although there is a deadline of the 29/01/21 to submit requests for additional license grants for existing deployments of 32+core per sockets, I believe that VMware will have to commercially honour additional license grants for 32+core sockets that are deployed after the deadline up to ELA expiry. For this reason a robust conversation with your account manager may be worthwhile to get a concession to mutually ignore the deadline and deal with additional license grants at ELA renewal time.
Hi Simon,
Thanks for your comment. I’m afraid, I’m forced to disagree on both points, though there is not enough space here to answer fully. I’ve written a follow up article to cover the subject, which will be published in due course.
Thanks,
Barry