VMware Per-CPU vs Per-Core Licensing

The shift from per-CPU to per-core licensing is the single most consequential change in VMware's commercial model under Broadcom. Customers who came from the pre-acquisition VMware catalogue learned a per-CPU world: licences were sold per physical processor socket, with a 32-core cap per CPU above which a second licence was required. Customers under Broadcom now operate in a per-core world: every physical core in every licensed host is counted, with a 16-core minimum per CPU floor, and the unit price applies to every core.

The change is not a simple rename. The unit price arithmetic, the minimum-commitment provisions, the cost-of-density calculation, and the audit-reconciliation method are all different. Customers who treat per-core as a relabelled per-CPU underprice their renewals by meaningful margins, miss optimisation opportunities, and produce audit findings driven by counting-method confusion.

The per-CPU model as customers remember it

The pre-acquisition VMware model licensed vSphere, vSAN, and related products on a per-CPU basis. The unit of charge was the physical processor socket. Each licensed host required one licence per socket, regardless of core density — a single-socket host required one licence, a dual-socket host required two, and so on.

The model included a 32-core ceiling per CPU. CPUs containing more than 32 physical cores required additional licences proportional to the over-32 core count — a 40-core CPU required two licences. The change was introduced in 2020 in response to the increasing core density of server CPUs, and it represented the first per-CPU model adjustment toward per-core counting.

The mental model the per-CPU world produced for customers was simple: cost scales with socket count. Adding cores to a socket without adding sockets did not increase licensing cost; refreshing hardware to higher-density CPUs reduced cost per workload. The economic incentive was toward higher-density servers and toward consolidation onto fewer sockets.

The per-core model Broadcom introduced

The post-acquisition catalogue licenses VMware products on a per-core basis. Every physical core in every licensed host is counted, and the unit price applies uniformly across cores. The minimum-commitment provision applies a 16-core floor per CPU: a CPU with fewer than 16 physical cores is licensed as 16 cores regardless of actual core count.

The minimum-commitment provision also applies at the subscription level, with a 72-core (currently — subject to catalogue updates) per-subscription floor for VCF. Customers below the floor still pay the floor; customers above the floor pay actual core count.

The change to per-core eliminates the consolidation-onto-fewer-sockets incentive. Cost now scales with core count, not socket count. Higher-density servers no longer reduce per-workload licensing cost — they typically increase it, because the same workload running on more cores produces a larger licensing footprint.

How the 16-core minimum per CPU actually applies

The 16-core minimum per CPU is the most commonly misunderstood per-core provision. The minimum applies per physical CPU, not per host, and is a floor not a cap.

Worked example: a dual-socket host with two 12-core CPUs has 24 physical cores. Under straight per-core counting, that would be 24 cores of licence. Under the 16-core-per-CPU minimum, each CPU is licensed at 16 cores regardless of the 12-core physical count — producing 32 cores of licence on the 24-core host.

A dual-socket host with two 20-core CPUs has 40 physical cores. The minimum does not apply because each CPU exceeds the 16-core floor. The licence count is 40 cores.

A dual-socket host with one 12-core CPU and one 24-core CPU is licensed at 16 + 24 = 40 cores: the 12-core CPU is rounded up to 16; the 24-core CPU is licensed at actual count.

The provision targets lower-density CPUs typical of older or smaller servers. Customers with older infrastructure containing 8-core or 12-core CPUs see the largest minimum-floor effect. The natural mitigation is hardware refresh toward CPUs that exceed the 16-core floor, but only where the refresh economics overall work.

The 72-core subscription minimum

The 72-core subscription minimum (current catalogue floor, subject to revision) applies at the VCF subscription level. The minimum is enforced at first purchase and at certain renewal events.

The practical effect is that VCF is not available to customers below a certain estate scale. A small customer with a single dual-socket host of two 16-core CPUs (32 cores) cannot purchase VCF for that host alone — the subscription minimum demands at least 72 cores of commitment. Customers in this position must either commit to additional cores beyond their actual deployment, find a deployment scope that meets the floor, or use a different licensing vehicle.

The minimum is set deliberately to push smaller customers toward partner-delivered managed-service models rather than direct VCF subscription. Customers caught in this gap should evaluate the partner-delivered alternatives carefully.

Per-core arithmetic and unit pricing

The per-core unit price under Broadcom is published in the catalogue but is materially negotiated on actual deals. List per-core pricing for VCF varies by edition; effective pricing on negotiated deals frequently sits below list for larger commitments. The Broadcom pricing model rewards larger commitments, longer terms, and clean renewal histories.

Per-core list pricing as of mid-2026 catalogue: VCF Advanced sits in a band around $350 per core per year list (subject to negotiation, edition, region, and term); VCF Enterprise sits meaningfully above that band. Effective deal pricing typically sits below list. Standalone vSphere Foundation and vSphere Standard pricing carry distinct per-core values.

The arithmetic is straightforward: licensed cores multiplied by the per-core unit price multiplied by the contract term length, with discounts applied. A 500-core VCF Advanced deployment at a $300 effective per-core price on a three-year term is $300 × 500 × 3 = $450,000 over the term, or $150,000 annually.

Counting cores correctly

The audit-reconciliation method counts physical cores, not hyper-threaded logical cores. The distinction matters: a 32-thread CPU with 16 physical cores is counted as 16 cores, with the 16-core minimum applying if the CPU is below floor (which it is not in this example). The reconciliation uses CPU model lookup against vendor specifications.

The reconciliation counts cores in licensed hosts — defined as hosts where the licensed software is installed or running. Hosts running entirely separate workloads with no VMware footprint are not counted. Hosts running VMware in a development or test environment are counted unless explicitly excluded by entitlement.

The reconciliation includes powered-off cores. Hosts that exist in the cluster but are not actively running workload still count. Decommissioning rather than powering down is the correct approach for cores no longer required.

How hardware refresh decisions change under per-core

The per-core model changes the hardware-refresh calculation substantively. Under per-CPU, hardware refresh to higher-density CPUs reduced licensing cost per workload — the same workload on fewer sockets cost less to licence. Under per-core, the same hardware refresh increases licensing cost per workload, because higher-density CPUs increase the core count subject to per-core charging.

The break-even analysis for hardware refresh under per-core requires two-axis thinking: hardware cost and operational savings on one axis, licensing-cost uplift on the other. A refresh that consolidates from older 12-core CPUs to current 64-core CPUs increases licensing cost on the licensed cores by roughly 5x for the same workload, even as it reduces hardware cost, power, and rack-space cost.

The mitigation strategy varies by deployment. Customers with cluster-level isolation between licensed VMware and unlicensed workloads can refresh selectively, keeping the licensed cluster on lower-density CPUs while refreshing other clusters more aggressively. Customers running a unified compute fabric do not have this flexibility and must accept the licensing-cost uplift as part of the refresh decision.

Cluster sizing and host count optimisation

The per-core model produces specific optimisation patterns at the cluster-design level.

Fewer, denser hosts vs. more, sparser hosts

The trade-off between consolidating onto fewer denser hosts (reducing host count, power, rack space, hardware cost) and operating more sparser hosts (reducing per-host core count, potentially benefiting from the 16-core minimum) is now a relevant licensing-design question. Most enterprises will continue to favour denser hosts on operational grounds; the per-core licensing cost is the offset.

Cluster-membership scope

Cores in licensed clusters count; cores in unlicensed clusters do not. Customers running multiple workload classes with different licensing requirements can isolate VMware-licensed clusters from non-VMware clusters to bound the licensing footprint.

Dev/test scope

Dev and test environments are subject to per-core licensing the same as production. The historic practice of using less-stringent licensing for dev/test under per-CPU is no longer available. Customers running large dev/test estates need to either license them, run them outside the VMware-licensed scope, or accept the per-core charge.

Negotiating around per-core mechanics

The per-core mechanics produce specific negotiating handles at the deal point.

Minimum commitment scope. The 72-core minimum is the published floor, but the practical commitment Broadcom expects scales with the customer's actual deployment. Customers committing at the floor for an estate that will deploy substantially more cores within the term should expect renewal renegotiation; right-sizing the initial commitment to deployment trajectory is the discipline.

Per-core unit price. The per-core unit price is the principal negotiable on most VCF deals. Discount stacking based on volume, term length, and commitment cleanliness is the lever; benchmark pricing from comparable peers (via external advisory) is the input that supports the discount discussion.

Edition selection. Advanced vs. Enterprise carries a meaningful per-core price differential. Right-sizing edition to feature usage rather than to aspirational future state is the discipline.

Term length. Longer terms (three to five years) typically produce better per-core pricing in exchange for the commitment. The trade-off is term risk; longer terms lock in pricing but also lock in commitment.

The customer profiles most affected by per-core

Three customer profiles are most affected by the per-CPU-to-per-core change.

Older hardware estates

Customers running infrastructure built around 8-core or 12-core CPUs are most affected by the 16-core minimum. The minimum produces a meaningful licensing inflation relative to actual core count, with the only mitigation being hardware refresh toward CPUs above the floor.

Higher-density modern estates

Customers running infrastructure built around 32-core or 64-core CPUs (current high-density commodity) are most affected by the absolute per-core charge, because the licensed-core count scales linearly with the CPU density. The mitigation is workload-density optimisation and cluster-membership scope discipline.

Hardware-refresh-pending customers

Customers planning hardware refresh under the previous per-CPU economic model and not yet executing the refresh need to revisit the business case. The per-core economics shift the refresh decision substantially.

The transition from per-CPU contracts to per-core renewals

Customers with active perpetual per-CPU entitlement face a transition at renewal that requires careful arithmetic translation. The conversion from per-CPU perpetual to per-core subscription is the principal mechanical step.

The conversion typically proceeds as follows. The customer's current per-CPU perpetual entitlement is translated into a notional per-core entitlement based on the licensed hosts' core counts. The notional per-core figure is then used as the basis for the subscription commitment. The per-core unit price under the subscription is applied to produce the annual subscription cost.

The arithmetic does not always favour the customer. Customers with low-core-density hardware see the floor-adjusted core count exceed the original per-CPU count, producing larger per-core commitment than the per-CPU count would suggest. Customers with high-core-density hardware see the per-core count substantially exceed the per-CPU count.

The mitigation strategies during conversion include: right-sizing the destination edition to deployed feature use rather than to incumbent edition; sizing the commitment to deployment trajectory rather than to nominal historic peak; negotiating transition support or migration credits to soften the first-year cost impact.

How per-core counting affects specific workload types

The per-core arithmetic affects different workload types differently. The differential affects the renewal economics across the workload mix.

Compute-intensive workloads (typically large per-VM core allocations, high CPU utilisation). The licensed cores supporting these workloads are well-utilised; the per-core cost is offset by the high per-core workload value.

Memory-intensive workloads (large per-VM memory, lower per-core CPU utilisation). The licensed cores are over-provisioned relative to the per-core workload value; the per-core economics are less favourable.

I/O-intensive workloads (storage or network-bound, lower per-core CPU utilisation). Similar to memory-intensive: licensed cores exceed the per-core workload value.

Burst workloads (highly variable utilisation, peaks much higher than averages). The licensed cores need to be sized for peak; the per-core cost is paid against the average utilisation. Cloud-burst patterns may be a more efficient model for these workloads.

Operational discipline under per-core

Several operational disciplines support good per-core economics over time.

Continuous capacity-utilisation tracking. Maintain ongoing visibility into the actual utilisation of the licensed cores; identify under-utilisation as an opportunity for consolidation or for entitlement reduction at renewal.

Workload-level rationalisation. Identify workloads consuming disproportionate licensed-core resource for their business value and consider rationalisation, migration to less-resource-intensive deployment, or retirement.

Dev/test scope discipline. Dev/test environments are subject to per-core licensing; bound the dev/test scope explicitly rather than allowing uncontrolled expansion that produces meaningful licensed-core inflation.

Hardware-refresh modelling. Model the licensed-core impact of hardware refresh decisions before executing the refresh; the impact may exceed expectations under per-core economics.

Related reading

For deeper context on adjacent topics, see the VMware licensing complete guide, VCF licensing explained, subscription conversion pricing, and our VMware audit defence guide.