The VMware/Broadcom per-core minimum, explained
· 6 min read
After Broadcom acquired VMware, perpetual licenses gave way to per-core subscriptions — and a per-CPU minimum that can inflate your license count well beyond the cores you actually run. Here's the mechanic.
Per-core, with a floor
VMware subscriptions (VCF, vSphere Foundation, and others) are now counted per physical core. The catch is a 16-core-per-CPU minimum: each populated CPU socket is licensed for at least 16 cores, even if the physical processor has fewer.
So a host with two 12-core CPUs has 24 physical cores — but licenses as 32 (16 × 2). On a fleet of hosts with sub-16-core sockets, that floor compounds into a meaningful gap between physical cores and licensed cores.
Where the surprises come from
- The minimum itself. Teams size on physical cores and forget the 16-core floor, under-counting requirements per host.
- Perpetual-to-subscription migration. Existing perpetual licenses don't carry over cleanly; the renewal or audit reprices the estate under the new per-core model.
- Edition mapping. VCF, vSphere Foundation, vSphere Standard, and add-ons like vSAN have different entitlements; the wrong edition mapping misprices the position.
- Unrecognized keys. License keys that don't resolve to a known product force assumptions — which should be verified against the Broadcom portal, not guessed.
Getting to a defensible number
The compliant requirement is: for every host, the greater of its physical cores or the 16-core-per-CPU minimum, summed across the fleet and mapped to the right edition — then compared against what you're entitled to. Done by hand across a large estate, it's error-prone; done continuously, it's an early-warning system.
RenewalIntel applies the post-Broadcom per-core model — including the 16-core floor and perpetual-migration analysis — and prices the gap with the calculation shown, so you walk into the renewal knowing your real position.