VMware announced a change to their per-CPU pricing model yesterday. Starting April 2, 2020, ALL software that is licensed per physical CPU (also called “per-socket” licensing by some vendors) will be limited to 32-cores per CPU. Thus, if you need to license a CPU with more than 32 physical cores, you’ll be required to purchase an additional license.
We’ve known, especially here at AdoredTV.com, that AMD EPYC CPUs would sport up to 64-cores for quite some time now. We’ve also known that Cascade Lake Xeons would glue together two Xeons on-package to double their core count capability on the high end, similar to how the Pentium D or Core2 Quad CPUs worked. This growing core count per socket has lead to significant performance improvements per server, which for organizations that don’t have rapidly growing compute demand means the potential to reduce their overall physical server footprint. This means fairly significant licensing cost savings for per-socket licensed software, or from another point of view, fairly significant revenue decline for said software vendors. Especially for VMware, as they had 75.1% of the server virtualization market (according to a survey) near the end of 2017.
The writing was on the wall when Microsoft switched from per-socket licensing to per-core licensing with Microsoft SQL Server 2012, followed later by Microsoft Windows Server 2016. VMware had remained a large software provider for datacenters that was still on per-socket licensing. Being over a datacenter myself, for the past two years when meeting with our VMware sales representatives, one of my first questions has always been about future licensing structure changes, as 2-to-1 or better CPU consolidation is readily available in the current upgrade cycle and would certainly be affecting VMware’s bottom line.
Image Credit: AMD 
You may recognize these slides from our EPYC Rome launch coverage, promising us lower licensing costs and greater server density, leading to a lower TCO. DellEMC themselves have promised similar benefits for their AMD line of PowerEdge servers.
To help ease the transition, VMware is offering a grace period where customers who purchase VMware software licenses for deployment on a physical server with more than 32 cores per CPU, prior to April 30, 2020, will be able to request an additional free per-CPU license to cover the CPUs on that server. This will certainly take a bit of the sting out of this licensing change, but only temporarily. Support licensing will obviously become a factor as renewals come in, essentially doubling the ongoing costs from what they would have been.
VMware is no stranger to controversial licensing changes unfortunately. When they launched VMware ESXi 5.0, they introduced a vRAM limitation of just 24/32/48GB per socket license (depending on license version of Standard/Enterprise/Enterprise Plus), so if you had a dual-socket server with 128GB of RAM, you’d have to purchase four (4x32GB=128GB) VMware Enterprise licenses where only two was necessary in VMware 4.x. Since this was back in 2011, having more than 32GB per socket was rather common for many, especially at the enterprise level. The backlash from the users was so harsh VMware capitulated and doubled the vRAM “entitlements” to 48/64/96GB per socket. That pricing policy was in place for a full year until, just before the release of ESXi 5.1, VMware removed the vRAM (and, less impactful, CPU core) restrictions altogether and adopted our current now-ex licensing scheme. We’ve even seen the elimination of an entire tier of pricing, with the removal of the “Enterprise” ESXi license tier, forcing customers to move up to the more-expensive Enterprise Plus license which had a handful of additional features unlocked, but were obviously not needed by the previous “Enterprise” customers.
Now, since Xeon-based servers in current use have been limited to 28-cores at best, and the majority of EPYC-based systems will have been Naples (32-cores) or Rome (up to 64-cores), a huge portion of current customers will essentially be unaffected by this change for their existing environments. In planned capacity upgrades, 48 or 64-core systems would have been dual-socket systems anyway and would have been accounted for as such. Really, it’s AMD EPYC Rome’s offerings of 48 and 64 cores, and the potential halving of socket-based licensing costs, that make this licensing change bitter. Had this policy change occurred two years ago, it may have had less impact, but making this change after months of “lower TCO” marketing and many in the datacenter designing server refreshes with high-core-count EPYC or Intel’s forth-coming Cooper Lake Xeons will now be slapped with higher licensing costs and potentially altering expansion plans. Fortunately, the majority of 48- and 64-core servers likely went to cloud providers which run custom solutions built on top of mainly KVM or Xen opensource projects. Which leaves the remainder of us to now design up to 32-cores-per-socket systems, and if we want to take the licensing hit of more than 32 cores, we’d be better served running dual socket 32-core systems rather than a single 64-core setup (mostly due to the extra memory channels and maximum RAM capacity considerations).
Since Intel’s Cooper Lake high-core-count CPUs are not due out until later this year, and the glued Cascade Lake high-core-count Xeons are virtually non-existant, as they’re special order setups, the only CPU manufacturer that will really be impacted is AMD. However, since 32-core EPYC Rome CPUs only use four chiplets instead of the six or eight of the 48-core and 64-core SKUs, AMD doesn’t lose much besides the higher margins on the top-end EPYCs and the additional packaging and I/O dies utilized by two 32-core CPUs in lieu of a 64-core chip.
We can only hope that customer backlash will eventually relax or eliminate this new restriction, as it did in the vRAM licensing era, or CPU makers engineer a way around the problem. It’s rumored AMD’s Zen4 core will have 4-way SMT, giving a 32-core CPU a total of 128 threads. This would potentially give them a huge advantage verses Intel Xeons in the new world of VMware licensing restrictions, especially in a world where VMware’s continued recommendation for Spectre mitigations is to disable Intel’s Hyperthreading altogether.
The remaining spectre of this change is the ecosystem ripples it will cause, as other vendors may likely change over to per-core licensing models. Veeam, practically a staple of VMware virtual machine backups, is licensed per socket to match VMware and would be ripe for a similar licensing change, just to name one major ecosystem partner.
As technology advances and software becomes more integral to the datacenter with software-defined-everything, actual hardware costs become more-eclipsed by the software that runs on them, much to the dismay of IT budgets. Of course, Hyper-V, Citrix, ProxMox, Xen, and others haven’t been idle, and may offer great value on another look. VMware’s own missteps have certainly driven customers away in the past.
