Under Broadcom, VMware is licensed per physical core, with a minimum of 16 cores charged for every populated CPU socket. The Admodum read on the arithmetic, worked examples, and the consolidation play that lowers the billed core count.
Under Broadcom, VMware moved from per-CPU-socket licensing to per-core subscription. The buyer counts every physical core in every processor that runs VMware software and pays an annual subscription fee for each one. The bundle — VMware Cloud Foundation or vSphere Foundation — sets the per-core rate; the core count sets how many times that rate is charged. Admodum is an independent, buyer-side software licensing advisory, and this page explains the core-counting rule precisely, because it is where many renewal quotes quietly overstate the number.
The shift to per-core matters because it ties cost to processor density. Under the old per-socket model, a buyer paid the same for a socket whether it held eight cores or forty. Under per-core, the forty-core processor costs five times the eight-core one — except that the minimum, described next, changes the arithmetic at the low end. The wider model sits in the pillar at Broadcom VMware licensing: VCF, VVF and per-core subscription.
The 16-core-per-CPU minimum requires that every populated CPU socket be licensed for at least sixteen cores, regardless of how many cores the installed processor actually has. It sets a floor on the per-socket count, not a cap.
The rule resolves simply once the floor is understood. A processor with eight physical cores is billed as sixteen, because sixteen is the floor. A processor with sixteen cores is billed as sixteen, exactly at the floor. A processor with twenty cores is billed as twenty, and one with thirty-two cores as thirty-two, because both exceed the floor. The minimum therefore only adds cost where a processor has fewer than sixteen cores; above that line, the buyer pays for the real cores and nothing extra. The crucial consequence is that low-core-density hardware is penalised, while dense modern processors pay close to their true count.
The arithmetic is easiest to hold against concrete servers. The minimum applies per populated socket, so the server's socket configuration drives the billed count.
Take a two-socket server with two 8-core processors. It holds sixteen physical cores, but each socket is rounded up to the sixteen-core floor, so it is billed as thirty-two cores — double its real count. Now take the same workload on a single 32-core processor in one socket: it is billed as thirty-two cores with no penalty, because thirty-two exceeds the floor. Identical compute, identical billed count, but the second configuration carries no wasted licence. Push further: four two-socket servers of 8-core processors give eight sockets, a sixty-four-core minimum floor, against thirty-two real cores — the buyer pays for double. Consolidating those four servers' workloads onto two dense hosts can bring the billed count down toward the real count.
The pattern is consistent: the further a processor sits below sixteen cores, and the more sockets the estate spreads across, the larger the gap between real cores and billed cores. This is why the renewal arithmetic cannot be read from the old per-socket entitlement; it must be rebuilt from a current per-host core inventory, as set out at how to read a Broadcom VMware renewal quote.
It is worth stress-testing the count against the estate's edge cases, because these are where quotes most often overstate. Hosts in a disaster-recovery site that are powered but idle still run VMware and so still attract their socket minimums; clusters reserved for failover capacity are counted even when they carry no steady-state workload; and management or witness hosts that exist only to support the cluster are frequently included by default. Each of these is a legitimate target for review: a witness appliance does not need a full bundle entitlement, and a cold disaster-recovery site may be addressable through a different commercial construct. Reading the count line by line against what each host actually does, rather than accepting a single estate-wide figure, is how the billed total is brought back to what the workload genuinely requires.
Because the minimum penalises sockets rather than compute, the billed count is reducible by changing how compute is packaged, without reducing the workload itself.
The move is to consolidate workloads onto fewer servers with higher-core-count processors, so fewer sockets attract the sixteen-core floor and the billed count converges on the real count. An estate of many two-socket, eight-core hosts is the worst case under the Broadcom model; the same workloads re-hosted on fewer dual-socket servers with dense modern processors can cut the billed core count materially. Retiring lightly used and low-density hosts before the renewal date removes their minimum floors entirely. The discipline pairs with hardware refresh: where servers are due for replacement, choosing high-core-count processors is now a licensing decision as much as a performance one.
Two cautions apply. Consolidation must respect resilience and failure-domain requirements — packing everything onto two hosts to save licence cost is a false economy if it removes redundancy. And the count must be based on a verified physical inventory, because quotes built from stale asset records frequently bill for decommissioned or double-counted hosts. The wider negotiation that consolidation feeds into sits at the VMware renewal negotiation playbook, and the case for leaving entirely at VMware exit and renegotiation strategy. The engagement sits at the Broadcom / VMware practice, the reading list at the Broadcom knowledge hub and the cluster index at the Broadcom and VMware hub; engagement opens at contact.
The per-core minimum permanently changes the economics of server procurement for any VMware estate, because licence cost now scales with socket count and processor density rather than with raw server numbers.
Before the Broadcom model, an organisation could buy plentiful low-core servers cheaply and license them per socket at modest cost. Now each of those sockets carries a sixteen-core licence floor, so a sprawl of small servers is expensive to license even when it is cheap to buy. The rational response is to weigh the licence cost of a hardware choice alongside its purchase cost: a smaller number of dense, high-core servers may cost more in hardware but far less in VMware subscription over a multi-year term. Bringing the licensing team into the hardware refresh decision, rather than treating the two as separate budgets, is now the discipline that protects the renewal. The interaction with subscription term length is covered at VMware co-term and true-forward mechanics.
Under Broadcom, VMware is licensed per physical core: the buyer counts every core in every CPU that runs the software and pays an annual subscription per core. This replaced the older per-CPU-socket model. The count is subject to a minimum of 16 cores per populated CPU socket, so low-core processors are rounded up to the floor.
The 16-core-per-CPU minimum requires that every populated CPU socket is licensed for at least 16 cores, even when the installed processor has fewer. A processor with 8 physical cores is billed as 16; a processor with 20 cores is billed as 20. The minimum sets a floor, not a cap.
A server with two 8-core processors holds 16 physical cores but is billed as 32, because each of the two sockets is rounded up to the 16-core minimum. The same workload on a single 32-core processor would be billed as 32 cores with no minimum penalty, which is why processor density matters under the Broadcom model.
Per populated socket. Each CPU socket that contains a processor is licensed for at least 16 cores independently, so a two-socket server has a 32-core floor and a four-socket server a 64-core floor. Empty sockets are not counted. This is why consolidating onto fewer sockets with higher core counts reduces the billed total.
Consolidate workloads onto fewer servers with higher-core-count processors, so fewer sockets attract the 16-core minimum and the billed count moves closer to the real core count. Retire low-core-density and lightly used hosts before renewal, and verify the physical core inventory so the quote reflects actual hardware rather than stale records.
The full post-acquisition model: VCF, VVF and per-core subscription.
The Admodum white paper on the Broadcom VMware transition includes the per-core arithmetic, the 16-core minimum and the consolidation play in full. A senior advisor will read your verified core inventory and consolidation potential against your quote on a private call.
Renewal approaching? Join the newsletter or route the moment to the Renewal Programme.