VMware has adjusted their per-cpu licensing model, used in cases where customers are licensing based on physical cores in a server. Specifically, in the current rarified atmosphere above 32 cores, such as with the AMD EPYC Rome 64-core or Intel Cooper Lake 56-core, you will require additional licenses.
|Number of CPUs and Cores||Licenses Required with Old Pricing||Licenses Required with New Pricing|
|1 CPU with 28 cores||1 CPU license||1 CPU license (up to 32 cores can be provisioned with 1 CPU license)|
|1 CPU with 64 cores||1 CPU license||2 CPU licenses (each licenses will provision up to 32 cores in this CPU)|
|2 CPUs with 32 cores each||2 CPU licenses||2 CPU licenses (each CPU needs its own CPU license of 32 cores)|
|2 CPUs with 64 cores each||2 CPU licenses||4 CPU licenses (each CPU needs w CPU licenses to support its 64 cores)|
VMware claims this brings them more in line with industry norms for enterprise software. Well, perhaps, but the vendor spin is always interesting in these cases.
This @VMware license change is like Southwest Airlines saying they will charge bag fees because that's what the rest of the industry does. Whenever a vendor starts a conversation with "license flexibility" read "price increase." https://t.co/8domgzsbkW— Keith Townsend (@CTOAdvisor) February 3, 2020
From a practical standpoint, there has always been an opportunity to create greater cost efficiency by leveraging what the chip vendors sometimes refer to as “up the SKU” or the high end of their lines.
They like it because there is more profit and the marketing messages portray big customer advantage, not just in performance but in cost efficiency. Beyond the emotional win of buying the most powerful gear possible, there are arguments for the trend toward larger clusters of capacity combined with software defined boundaries and control over it.
Technologies like network virtualization and resultingly larger mobility boundaries allow for large amounts of virtually contiguous capacity that can then be addressed much more flexibly. Not really a factor of course if you have a small environment, but in scale, these scenarios lend themselves well to safely using larger servers. Gaining the full advantage, however, does take some doing in the case of virtualized infrastructure. It’s one thing to use them for single purpose, scaled tasks such as database servers, but using them to underpin diverse virtualized workloads at scale is a different matter.
Fact is, even with VMware double dipping on these larger physical devices, managed well, there is potentially still a strong cost advantage.
If you have a way to make them truly busy and more densely-packed with workloads and related expensive software licenses, then it can work in your favor. Greater numbers of workloads on a single physical server yields higher VM-to-host ratios, and if you are clever about what goes onto those same servers with respect to expensive core-based licenses like Windows DCL, SQL, Oracle etc., then there are potentially big software cost advantages.
The issue for many is twofold: once you have this capacity, how do you confidently and safely place as much as possible onto those beasts? And, in the case of the software license management question, how do you prevent expensive core-based software from spreading like smoke across all these highly scalable servers and artificially ramping associated license costs. When you combine the challenge of finding the optimal combination of workloads and the software license complexity it becomes a daunting thing to manage and optimize.
Placement optimization and resource control analytics can provide the answers required to compliantly and safely choose the right combinations of workloads (dovetailing) to get you to a great place from a density perspective. With the right attention to the other rules that could impact which workloads are allowed to be on the same physical device (example: risk deconcentration), you can end up with these large servers running very smoothly, well utilized and from a governance perspective, on side with the other considerations.
From a software license control perspective, adding rules that address or software define which types of licenses you would like to “defragment” onto smaller numbers of physicals and you can gain a huge win there too.
So, while it’s never a good thing to hear that a required piece of software is going to cost more, in this case it shouldn’t deter you from making the move to 64 cores in a VMware environment. Provided you have the means to cram those servers full of work, and layer in intelligence around software license control, the cost benefits could be very large.
See how Densify can help you maximize the utilization of each of your VMs: Request a short 1:1 demo with one of our Cloud Advisors.Request a Demo