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.

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.

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

Minimum of 16 cores per physical CPU, 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. Two weeks later the same channel reported it had been walked back, with German outlet iX among the first to say so. Broadcom told press it had not announced a price change. Reporting at the time also had the rule reaching some regions and not others.

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. Everything above it has moved by channel, by region and by quarter.

The practical advice is unglamorous. 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, and that line does not appear in the first draft of a 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. Covered above and worth repeating: 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.

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 of spare capacity that is now paying for itself in 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 warns that its own counting script under-counts 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 and VMware optimisation as fixed-price engagements: 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 our partner Vixen.UNO (a VMware Premier Partner and Broadcom Technology Alliance member, with twelve engineers holding current VCP and four holding VCAP*) under one European contract with us.

We are not a licence auction house and we will not tell you the platform is wrong. Most estates we look at should stay where they are and be counted properly. See VMware optimisation and infrastructure audit for how those engagements run.

*figures: Vixen.UNO engineering team

FAQ