VMware’s Licensing Change Redux: Better the Second Time Around

The year was 2011. I was comfortably ensconced in my office at Westminster College watching as VMware brought out a marketing executive to discuss the company’s revolutionary new licensing program. As soon as I saw that it was a marketing person giving the news about a change in licensing, I thought to myself, “This isn’t going to be a positive announcement.”
And it wasn’t.
vSphere 5’s vRAM licensing model quickly became known as the vTax or vRAM Tax and was derided as being anti-customer, which it was.  VMware, like most companies, grows revenue by adding new products and by charging more for the products they already sell.  vRAM licensing worked by aggregating all the virtual RAM operating in your environment and doing some division based on vRAM entitlements in your vSphere edition.  For years, VMware had implemented various memory management technologies and sometimes guided customers to add lots of vRAM, just to make sure that their workloads had what they needed.
And then they pulled a licensing trick out of their hats and, in the process, they made a whole lot of people really mad.
In short, it was confusing, anti-customer and a failure for a lot of reasons.  Just over a year later, VMware abandoned the plan and returned to a CPU-centric licensing model.
Recently, VMware made a change to its vSphere licensing model again.  Did they remember the lessons from the vRAM debacle?

New Era, New Licensing

VMware introduced a major update to its licensing policies for vSphere.  Prior to this announcement, if you had a server with two processors, you paid for two licenses.  It’s pretty simple match.  However, as we enter an era in which there is increased opportunity for server consolidation thanks to behemoth core counts from Intel and AMD, VMware and jumping onto the per-core licensing bandwagon, at least to a point.
I do think the company learned some lessons from the dreaded vTax and kept the new program a bit simpler and far easier to manage than what they tried to do so many year ago.  Now, vSphere licenses are limited to 32 cores.  If you have a 64-core CPU, you need two licenses to support it.  It’s not great news for organizations that prefer a fewer number of dense servers versus a lot of smaller servers, but it does reflect the reality of a hardware market that keeps expanding core counts.  And, frankly, it doesn’t really impact a huge part of their customer base (at least for now) since processors with more than 32 cores are still pretty hefty budget busters.  Moreover, other resources, such as RAM, are typically the first to be constrained anyway, so this change will not likely have a major impact on most organizations, except those that are heavily reliant on compute vs. RAM, storage, and other services.
Any licenses purchased after April 2, 2020 will be sold under the new program.  For current customers, though, VMware has provided a mixed bag of news.

• On the good news front, if you have current servers with core counts that exceed 32 cores, VMware will top you up. They’ll grant you new licenses at no charge to cover excess cores so that you don’t suddenly lose half your computing power after April 2.
• However, on the maintenance and support front, this line appears in VMware’s FAQ on the change: “Note that customers will be charged for Service and Support on the additional free licenses at the time the customer’s Service and Support contract for the existing licenses renews.”

In other words, even if you’re granted free licenses, you’re going to see an increase in maintenance and support costs.
VMware indicates that the vast majority of their customers won’t be impacted by the change.  I tend to agree, although this is true only today.  Over time, more customers will seek 64-core CPUs, and this change will absolutely have an impact.  And, it will have an immediate impact on customers in terms of maintenance renewal.

My Thoughts

As core counts increase, I see why VMware needs to ensure that their licensing value remains consistent.  The company could have simply doubled the cost for new licenses and maintenance, but that would have had an outsized impact on all their customers.  Instead, they addressed the direct issue – core count – and didn’t try to do something weird and complex, which would have just introduce confusion.
The biggest downside is that existing customer with behemoth processor counts will face an impact in the form of support and maintenance costs, even with the free top-up licenses.  I suppose that’s unavoidable as trying to track which license is which could be ultimately nightmarish and would also serve to confuse.
VMware also indicates that their new licensing mechanism aligns the company with the methods by which other vendors are licensing product.  Personally, I don’t particularly like this as a reason.  Per socket CPU licensing is quite a bit simpler to deal with than anything that move into per-core territory and this sounds more like VMware is grasping a bit to justify their licensing change when a simple “revenue it taking a huge hit from massive core counts, so we’re maxing out at 32 cores per license” would have sufficed.
I’ve seen some express concerns that the licensing change will impact hardware sales and we’ll see core counts decrease in servers. Personally, I don’t see this.  Customers will still need that compute capability and they’re going to have to buy licenses whether they add lower core count servers or higher core count CPUs. The changes will result in more revenue for VMware in these scenarios.  But, again, if the choice for VMware was whether to massively increase the cost for all licenses or put an upper limit on the core count and I believe they made the right decision.
In closing, overall, the new licensing scheme isn’t terrible, has relatively minimal impact on all but the biggest servers, and helps ensure that VMware can maintain a reasonably consistent revenue stream for their core product using a method that is super simple to grasp.