VMware licensing after the Broadcom change: how to count what you actually need

What actually changed

Two things, and only one of them gets discussed. The visible change is that VMware moved to subscription: there is no perpetual licence to buy any more, and the renewal is the whole cost, not a support percentage on top of an asset you already own.

The quieter change is the packaging. A long list of individual products became a short list of bundles, and the bundle you land on determines what you are paying for whether you use it or not. The four you will see on a quote:

Contents and term options have moved more than once since 2024; treat this as the shape, and the quote as the fact. vSphere 9.x ships only inside VVF and VCF; how the two differ is in our VVF vs VCF comparison.

The practical consequence is that the interesting question is no longer “which features do we license” but “how many cores are we presenting to the invoice, and did we mean to”.

How the core count is calculated

Broadcom’s own rule is short. You license every physical core in every host that runs the product, and you license a minimum of 16 physical cores per CPU socket regardless of how many cores that CPU actually has. Hyperthreading does not enter into it: logical processors are not counted. Broadcom’s KB 313548 provides a PowerCLI script that takes the count per host; our step-by-step guide runs it.

The minimum is where small estates get hurt. It rounds up per socket, every time:

Minimum of 16 cores per physical CPU (8 for VCF Edge), applied per socket and then summed across hosts

Read the last row again, because it is the one that shows up in real estates. Four older low-core-count sockets bill 64 cores. The same total compute on two modern 16-core sockets bills 32. Nothing about the workload changed; the invoice halved.

The 72-core story, and why not to plan from headlines

In late March 2025 the channel reported that Broadcom was raising the minimum purchase to 72 cores per order, per product, effective 10 April. In April distributors and the German magazine iX reported that the change had been withdrawn, and a Broadcom spokesperson told iX that Broadcom had not announced a price change and that the 16-core minimum set in December 2023 was unchanged. Reporting at the time had the rule reaching some regions and not others; a UK reseller reported a 72-core purchase minimum for UK purchases from 1 December 2025, and Broadcom’s own vmware.com site still hosts an undated video titled “Broadcom’s New 72-Core Order Minimum Explained”.

What survives all that is a single stable fact: the documented rule is 16 physical cores per CPU, and it is published in Broadcom’s own knowledge base. Reports of anything above it have differed by channel and by region.

Do not build a budget from an article, ours included. Ask your reseller for the core count they intend to quote, in writing, with the minimum rule they are applying, before you agree to anything. If the number is larger than your physical core count, the difference has a name and they can tell you what it is.

What comes bundled, and the add-on that surprises people

The Foundation bundles include vSAN capacity, and the amount scales with the cores you licensed rather than with the storage you have:

Counted against total raw physical capacity contributed by hosts to vSAN clusters, not usable capacity after policies

Two details cause most of the surprises. First, the entitlement is measured against raw capacity: the physical disks the hosts contribute, not the usable space left after RAID or erasure-coding policy. An estate that looks like it fits can be over the line once you count raw. Second, if you exceed the entitlement you buy additional vSAN TiBs as a separate line, so ask for that line in the first draft of the quote.

If you are running vSAN, count your raw capacity before the renewal conversation, not during it.

Where the number gets bigger than it needs to be

Four patterns account for most of the gap between what an estate pays and what it needs to pay. None of them require changing platform.

1. Host sprawl on old sockets. Many small hosts with low-core CPUs is the most expensive possible shape under a per-core rule with a per-socket floor. Consolidation used to be a capacity argument. It is now a line item.

2. Dev, test and DR hosts on the production SKU. They run the same hypervisor, so they inherit the same bundle by default. Whether a cheaper bundle covers what those hosts actually do is a question worth asking once a year, and it is rarely asked; on 9.x a VCF-licensed vCenter accepts no VVF licence, not even as an override.

3. Cluster headroom nobody re-derived. A cluster sized for N+2 when it was built, that has since had its workloads right-sized, may be carrying a host’s worth of spare capacity that now costs licence cores every year. The headroom policy should follow the current workload, not the one from three refresh cycles ago.

4. Cores that are switched on and doing nothing. Some platforms allow cores to be disabled in firmware. That does not reduce the licence count: Broadcom’s programme documentation states that every core on the server must be licensed, including cores deactivated in the BIOS, and Broadcom’s core-counting article warns that its script may produce inaccurate results when cores are disabled. The only way to present fewer cores is a smaller processor or fewer hosts.

A worked example

A mid-size estate runs six hosts, each with two 10-core CPUs. Physical cores: 120. Cores billed: 192, because each of the twelve sockets rounds up to 16. The estate is paying for 72 cores it does not own.

The workloads on those six hosts, measured over a month, fit inside three modern hosts with two 24-core CPUs each: 144 physical cores, and 144 cores billed, because every socket is comfortably above the minimum. That is 48 fewer licensed cores than the old estate, with more compute, less power, less rack and three fewer hosts to patch.

Whether that trade is worth the hardware is arithmetic you can only do with your own numbers: the licence delta over the subscription term, against the servers, the migration effort and the remaining life in the existing hosts. Sometimes it is obvious. Sometimes the honest answer is to keep the hosts and fix the bundle instead. The point is that under per-core subscription the two questions are now the same question, and estates that still treat hardware and licensing as separate budgets are the ones paying the most.

What we do

Eurokommerz runs infrastructure audits as fixed-price engagements, and VMware optimisation starts with a technical assessment whose price is fixed before work begins: we count the cores your current layout presents to the invoice, measure what the workloads actually use, and give you the consolidation options with the licence delta attached to each. Engineering is delivered by the team of our engineering partner Vixen.UNO under one European contract with us.

We are not a licence auction house: if there is nothing to optimise, we say so, and some estates should simply stay where they are and be counted properly. See VMware optimisation and infrastructure audit for how those engagements run.

FAQ