We called this one last year in Why 2019 Foreshadows the Per Socket Licenseageddon. Now VMware has finally overhauled its licensing model moving to a newer per-core license scheme. Frankly, VMware needed to make this change in 2020 as we pointed out last year. Many consumer-focused sites were quick to point out the fact that the new model “disadvantages” chips like the 64-core AMD EPYC 7742 we reviewed, even suggesting something sinister on the part of Intel in an anti-AMD campaign. To us, this storyline does not make sense. In this article, we are going to discuss what VMware did, why they did it, why AMD is not the most impacted by the change, what to expect next, and some strategies for dealing with the change.
Check Out the Video Version
If you are on the move and prefer to listen to this article, we have a version on YouTube as well. Here is the embed for that.
We know folks on STH prefer to read, but are providing this option on some of our articles.
VMware Moves to Per Socket and Core-Based Licensing
The VMware release was straightforward, but there are a few key points we wanted to point out. First, let us address what is happening. VMware is essentially stopping the practice of selling licenses on a per-socket basis. Instead, VMware is pivoting to selling per-socket licenses limited to 32-cores per socket.
In today’s model, one pays per socket. Whether that socket has 4 cores or 64 cores, you are licensing by socket. In the future, you purchase licenses per socket in increments up to 32 cores. Here is VMware’s diagram showing the difference.
This is not “per core” licensing. Each core does not have a price, nor is it based on global core counts. Instead, it is first based on sockets, then how many cores are in each socket. That is an enormous nuance in multi-socket servers.
If VMware was selling straight 32 core packs without socket restrictions, one could purchase two 16 core CPUs to fit in that 32 core licenses. Another valid model may be a 4-socket 8 core system with tons of RAM and PCIe connectivity. By keeping socket, VMware is effectively incentivizing buyers to hit the top core count and clock speed of a vendor’s SKU stack in 32 core increments.
Thus, from a licensing perspective, one would want 28-core CPUs like the Intel Xeon Platinum 8280 instead of 24 core parts like the Intel Xeon Platinum 8268. If you look at the current Intel stack, there are no 32 core mainstream CPUs. We expect Ice Lake Xeons to exceed 32 cores but not hit 64 cores which will completely change the segment of the SKU stack VMware buyers focus on in the next generation.
For AMD-based servers, this presents a different challenge. A 32 core AMD EPYC 7502P will look attractive, but a 48 core AMD EPYC 7642 processor will be highly disadvantaged. Had VMware went to a total core count licensing model, instead of retaining the per-socket grounding, the 48 core AMD parts would be much more attractive. 64 core parts like the AMD EPYC 7702P are going to require a second license. Many are focusing on those.
Why VMware is Making the Change
VMware says it is aligning its business model to other industry players. Frankly, for this it would have been much cleaner, and easier to transition to future evolutions if VMware dropped the “per socket” aspect of its licenses and just used a flat per core or per 16 or 32 core model. Perhaps the most cringeworthy sentence in the entire release is:
“We cannot continue pricing on a per-CPU basis, where CPUs could have unlimited core counts.” (Source: VMware)
VMware, and Dell Technologies, have a fairly good idea regarding where CPU roadmaps are. The companies have people who understand that you can only get so much performance per chip even with a large number of cores. Perhaps they felt threatened by the highly specialized Wafer Scale Engine accelerator that we recently featured on STH that is a gigantic chip. Still, there is no reason to go to unlimited.
Instead, here is a chart we used last year in our per-socket Licensageddon piece showing Intel core count growth by generation for eight generations of Xeons.
VMware was content through this cycle, especially as core count growth slowed drastically with Intel. Instead, when we look at the mainstream per-socket core count growth from 2009-2019, we noted in that piece that AMD is well beyond the trendline.
In the per-socket Licensageddon piece, we noted that this move outside of the trendline, coupled with AMD’s improving per-core performance, buyers could realistically purchase machines that sit well above the value growth trendline.
VMware is a business. It needed to react, and react specifically to the threat of greater than 2:1 consolidation to its business. As we highlighted in our recent 4-socket Intel Xeon Gold 6252 Benchmarks and Review piece, albeit using KVM virtualization, AMD is more than capable of these consolidation ratios:
At the end of the day, we can imagine Michael Dell and Pat Gelsinger going fishing together. Pat asks Michael for some bait. Michael replies, “these worms are not free.” The point being, VMware needs to uphold its financial obligations in the corporate structure, and plugging a risk for lost revenue is part of that.
AMD is Not the Most Impacted by VMware Change
When we think about the impacts of this change, things get interesting. Many have pointed to the 64-core AMD SKUs that now require two 32-core per socket licenses. AMD is undoubtedly impacted. Still, AMD has several 32-core options that can maximize the license better than Intel can. AMD also has options for something like a 4 core per CCD 32 core and 256MB L3 cache part that is clock speed optimized to further press this advantage.
One also has to remember that if one can truly consolidate two dual 32 core CPU servers into a single dual 64 core server, savings from buying and operating fewer servers will likely outweigh VMware license costs. If one thinks about it, two dual 32 core CPU servers are better for Dell Technologies as well since the server chassis, motherboard, power supplies, iDRAC controller and licenses and support are the unique Dell EMC portions of their PowerEdge offerings. This is a change that pays dividends beyond VMware licensing for Dell Technologies.
The bigger impact is around another 32-core CPU. STH readers will have seen our Cavium ThunderX2 Review piece. This is an Arm-based 32-core CPU with 4-way SMT for 128 threads per CPU core.
Arm is still working on getting per-core performance parity with Intel and AMD. Coincidentally, ever since VMworld 2018 we saw VMware ESXi 64-bit Arm Support Announced. VMware needs to get ESXi on Arm servers and endpoints for the edge, especially as next-generation infrastructure rolls out. We are seeing new Arm Neoverse offerings with high core counts such as the AWS Graviton2 and its 64 vCPUs and Huawei‘s 64 core offerings. Plus, Marvell, Ampere, and others will be in the market with greater than 32 core offerings soon.
Many of those companies are banking on using more cores and lower-than-Xeon initial purchase pricing to make them attractive primarily for cloud players. With the VMware licensing change, any high core count Arm CPU that cannot match AMD’s per-core with SMT enabled performance, is going to see that value proposition diminished.
This may not impact Arm in IoT devices, but anywhere that larger Neoverse designs can reach is potentially impacted. VMware will need a second license class to deal with this, which is why moving to per-core and not per-core plus per socket licensing would have been easier since one can create classes of cores and price them by core count regardless of topology.
Before we move on, you may have noticed that SMT has snuck in the discussion a few times. That Cavium (now Marvell) ThunderX2 chip had 4-way SMT capabilities. Current Intel and AMD chips have 2-way SMT. Licensing per core gives CPU designers the potential to increase SMT and get double-digit performance gains without incrementing core counts. If CPU designers focus on that in future designs, VMware will again need to come up with a per-core licensing metric that can take into account the relative performance of each core.
Dealing with Per Socket Licenseageddon Change
If you are buying servers between today and April 30, 2020, you can potentially get additional 32-core licenses that VMware is giving to higher-core count customers so long as the CPUs and licenses are purchased before that date. If you think this is a considerable impact to your current plans, add a time value of money factor to your TCO models to decide whether waiting to purchase a 64 core per CPU server in May to July 2020 is worthwhile or if those purchases should be brought in.
If you are firmly an Intel Xeon buyer, for the time being, there is no change. The Platinum 9200 series is available with higher core counts, but it has limited memory capabilities with only a single DIMM per channel and no Optane DCPMM support. As an STH tip, we are not purchasing Xeon servers in February 2020, instead pushing purchases to March 2020. We will leave it at that. Looking further than the next quarter, Ice Lake Xeons will present new challenges, however, given the scope of the VMware market, there is a good chance we will see a 32 core virtualization optimized SKU as the larger core count variants roll-out. Still that is a future product, so we are going to put that one firmly in the speculation basket.
If you were thinking about VMware on Arm server chips, call your VMware rep immediately. Tell them that planning a VMware on Arm project will need per-core licensing that makes sense. At STH, we want to see dual-socket Arm VMware servers in the market, but we also think that anyone planning for such deployment should be incentivized in the short term. Both Arm and VMware could use more momentum. It also helps when people think about what will be possible with AWS Graviton2 CPUs.
Overall, per-socket Licenseageddon is something that must happen. The trendlines we showed last year simply meant from a financial perspective, VMware needed to make this move to protect its revenue. We still wish that VMware dropped the socket concept from its per-core license since that opens up a lot more flexibility defining its product offerings alongside current and upcoming platforms. Using smart purchasing can help mitigate the short term impact and later in 2020 we will see new generations of Intel Xeon and AMD EPYC processors which means the companies can respond with offerings to drive even more value from the new license structure.
Someone actually THOUGHT and then wrote? This is the Internet. Your thoroughness has no place here. Give me a cat meme and unlimited VMware licenses for free to all of my offspring
It was just a matter of time, but at least it is capped at 32 cores and not at 16 cores like Microsoft.
There are possibly some “virtual cases” where 64 cores with 16 DIMMs makes sense, but I think 32 cores with 1TB RAM is a more balanced proposition, and that is possible with 64GB “value” memory. Having the same core/memory ratio with 64 cores is $8.000 more expensive with 128GB memory modules, and now on top of that twice the vSphere, vSAN and NSX licenses.
I wonder what is next, memory cap on vSphere or storage cap on vSAN.
Switch to another virt. platform that doesn’t have licensing, but support based model per host. Ideally Open Source 😉 And you can find some of them around (XCP-ng, oVirt, ProxMox…)
Greed will be the downfall of VMware, Microsoft etc. They want to increase their revenues by Moores law without adding value. Good luck with that.
Bye bye VMs!
Hello containers and open source!
I home this will give xcpng,opennebula,proxmox etc a pust, but unfortunately wont make a difference. Corps are still going to go with VMware.
This will only push VMware further into irrelevance.
Long past are the times when it was a cow. Then it became a dog. And now, as this article says… worms?
Well compare the TCO of a single epyc 64 core server to that of a dual socket Xeon 32 core and I pretty sure AMD comes out on top, I don’t really see how this change will hurt AMD in any significant way besides all the internet trolls that are still cheering for Intel.
1 Socket = 32 Cores as per VMware.
I presume once you switch to newer generation hardware you would have replace everything anyways when using VMWare? Why not simply ditch it instead? There is very good open source virtualization and you can buy support if you must at far more reasonable prices. As an added bonus you actually get people who can help you and who know the platform very well instead of people reading off a script and paying for a boatload of marketing, executives and dividends.
Nice to add vids.
– less intro
– consider where your viewers are coming from, and build your video around that
In my case, I already read the article title and intro, so the redundancy was a buzzkill. I love STH, and would love to see more content diversity—but only if it’s amazing content. Readers can scan multiple sections and pictures on the same page to parse and have a more meaningful content experience. You remove this ability, demanding all attention, with videos. The opening is critically important here! Start with a powerful lead-in, an abstract we associate with, or a very very impactful shared goal, or for this video, potentially teeing up your plan to share more video content moving forward before diving in.
give me a 32core CPU with 4 UPI links able to use 4TB of RAM per CPU running at 3GHZ+ and I will be very happy. I want 16TB of RAM with 256 threads running at 3GHZ+ for my SQL VM’s. 3 UPI’s hurt performance in big iron… and 4 UPI links are needed to fix that. Otherwise I’m looking at 2proc boxes with less cores. However 64 cores still lets me run 6 16 core SQL VM’s and some smaller vm’s at the same time. We used to be very leary of HT cores but SQL 2016 and 2019 seem to not care if it’s using a real core or a HT core.
Ok. So get 4 i9-9900Ks, arrange them 2×2 and laminate them in a square. Get (3d-print?) a fancy breadboard. Drop them onto four NUCs. 64GB RAM/thread, up to 5GHz if you can cool it well. Use 10G ethernet via Thunderbolt for IPC. Cost: ~$2500? (mostly for RAM)
To get your 16TB RAM +256 threads: same thing, just go 4×4 instead of 2×2. 😉
If a socket is a squarish connector with a lot of tiny pins (it is, yes?), and logic now allows 1 socket x 64 cores to equal 2 CPUs, while 2 sockets x 64 to be 4, I’d say it also perfectly stands to reason that 4 CPUs each with 8 cores easily can fit in a single “socket” (Just as sound an argument anyway). Time to design some new logic boards.