Image: AMD

It’s not a very good day for VMware users who are using (or planning to adopt) AMD’s most expensive EPYC parts. The cloud computing and virtualization software and service provider announced today that it was making big changes to its per-CPU pricing model.

Essentially, customers who utilize processors with more than 28 cores will be paying more from here on out. CPUs with 64 cores now require two licenses instead of just one, while a pair of 64-core chips will require four licenses.

Image: VMware

Again, this is bad news for AMD’s EPYC brand, which flaunts monster core counts. VMware says that it is making this change to “align” its offerings to “industry standard pricing models.” The company also claims that few of its customers use 64-core CPUs, anyway.

The good news is that VMware is offering a grace period for those with 64-core CPUs. Licenses purchased prior to April 30, 2020 will be “eligible for additional free per-CPU licenses to cover the CPUs on that server.”

Don’t Miss Out on More FPS Review Content!

Our weekly newsletter includes a recap of our reviews and a run down of the most popular tech news that we published.

Join the Conversation


  1. I wonder how long those free CPU licenses are good for… might get me some leverage to refresh our Vmware environment hardware.

  2. So it is only based on the license period you buy. So if you are putting in some 64 core systems and buying before april make damn sure the licensing period you get the grace licenses on is for longer than you plan on keeping the systems in service!

  3. I always thought a per core license made more sense than a per socket license.

    Why should someone with dual 8 core xeons pay more than someone with a single 16 core chip?

  4. [QUOTE=”Zarathustra, post: 10057, member: 203″]
    I always thought a per core license made more sense than a per socket license.

    Why should someone with dual 8 core xeons pay more than someone with a single 16 core chip?

    Honestly if you are doing more than demoing vmware on a dual 8 core system you are probably not too worried. 1. your pricing isn’t changing. 2. If you REALLY think that’s unfair look at your SQL enterprise licensing costs. THAT’s unfair to large installs.

    Yes we will have to roll with the blows of whatever Vmware chooses to do. From a budget perspective I can still spend more on hardware for a single host than I have to on licensing. With changes like this coming. (And I will state without a doubt that this will only get worse.) it will soon be like MSSQL enterprise where I’m starting to worry more about per core performance than number of cores. I don’t want to play that balancing game with my esxi hosts. I’d much prefer to build them as I want them and be able to easily plan my licensing costs.

  5. If they want licenses that scale, might want to do a benchmark based licensing and do it proper once for all.
    They can rank the cpus, and so on and so forth, come up with a price per cpu model, based on whatever metrics they want internally.
    This just sounds lazy.
    I get it, they want a type of price per pound licenses.. they gotta do it right once and for all.

  6. I knew density licensing was coming. They were losing out. It’s only going to get worse. I imagine in the next year or two we’ll see that halved again where they deem a 16C/32T CPU as the benchmark standard for a socket.

  7. They should stick to per socket or get licensing agreements from the big CPU vendors. Maybe negotiate licensing price breaks for AMD vs Intel CPU’s or whatever. Make the market a little more interesting. Like game bundling but for the enterprise!

    Buy AMD 72 core EPYC CPU’s, we bundle 2 ESXi Licenses per socket to help keep YOUR costs down! (Only if you install at least 2 TB of ram.)

  8. I don’t know how you would implement it technically, but a model where you pay for how many cores you use, not how many cores you have would be nice. For a hypervisor that’s not too difficult to imagine because you can specify how many CPU cores you provision out per VM. Seems like SQL Server follows (or at least used to) a similar business model – you pay per max cores you can allocate to SQL, not how many are installed on the system

  9. That would be a logistical nightmare for not only sysadmins, but vmware to enforce. Too many things change too rapidly in large environments for that to be viable.

  10. Speaking from a design perspective. If you license for every. Guest core allocated that defeats a lot of the benefit of VMware. We do 4 to 1.

Leave a comment