VMware licensing after Broadcom: the 16-core minimum and how to count the cores you need

VMware per-core licensing and the 16-core minimum

Under Broadcom, VMware vSphere Foundation (VVF) and VMware Cloud Foundation (VCF) are subscriptions licensed per physical core, with a minimum core count of 16 per CPU: a host with two 8-core CPUs is licensed as 32 cores. There is no perpetual licence to buy any more, so the renewal covers the whole licence cost, where it used to be a support fee on licences you already owned. We supply VMware licences and recommend the edition and term for your use case. Ask us which bundle fits your estate and our team will help.

The second 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 and VCF 9.1 comparison.

At renewal, the core count on the quote matters more than the feature list, so check that it matches the cores your hosts present.

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 has. Hyperthreading does not enter into it: logical processors are not counted. Broadcom KB 313548 (“Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN”) provides a PowerCLI script that takes the count per host; how to run it and read its output is in our guide to the Broadcom core count script (KB 313548).

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

The last row is common in older estates. Four low-core sockets bill 64 cores. If two current 16-core CPUs carry the same measured workload, the host bills 32, half the licensed cores.

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. The 72-core minimum rests only on these press and channel reports: we found no Broadcom document that sets it, and Broadcom KB 313548 (Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN) names only the minimum of 16 physical cores per CPU.

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. Before you sign, our estate and licence audit compares the cores on the quote with what your hosts present and what the workloads use. Send us the core count on your quote, and our team will check it against your hosts.

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. Under per-core licensing, consolidation changes the licence line as well as the capacity plan.

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 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.

Our estate and licence audit checks these four patterns host by host and lays out the consolidation options with the licensed cores for each. Tell us how many hosts you run and when your renewal is due.

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, with one host’s capacity still held back for HA: 144 physical cores, and 144 cores billed, because every socket is 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. How far a cluster can shrink under HA and vSAN host minimums is in our guide to host consolidation under per-core licensing.

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. In other estates it is better to keep the hosts and change the bundle. Put the server cost and the licence change over the subscription term in the same budget line.

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 for licensing, compare them with what the workloads use, and give you the consolidation options with the change in licensed cores for each. Engineering is delivered by the team of our engineering partner Vixen.UNO under one European contract with us.

If there is nothing to optimise, we say so, and some estates should stay where they are and be counted properly. See VMware optimisation and infrastructure audit for how those engagements run.

FAQ