VMware Per-Core Licensing

VMware is now licensed per physical core under Broadcom, with every core on every populated CPU counted, a 16-core-per-CPU floor, and a 72-core minimum per order since April 2025, so the licensed quantity is set by your hardware design, not your VM count. The per-core model replaced the old per-socket editions and is the single rule that drives every VMware bill, whether you buy Cloud Foundation or vSphere Foundation. This guide explains exactly how cores are counted, where the minimums inflate the total, how to calculate your real number, and the host-design choices that lower it.

Per-core counting is the foundation under both bundles in the VMware Broadcom licensing guide, so getting the number right is the first step in any quote, renewal, or exit analysis. Start from the VMware intelligence hub for the full vendor context.

From per-socket to per-core

Before Broadcom, vSphere was licensed per CPU socket, with a soft core limit per socket. A dual-socket host was two licenses regardless of how many cores each CPU held, which favored dense, high-core-count processors. The per-core model inverts that logic. Now every physical core counts, so a dual-socket host with two 32-core CPUs requires 64 core licenses, and adding cores adds cost linearly. The metric change alone raised costs sharply for customers who had standardized on high-core-count CPUs to minimize socket licenses.

The metric is physical cores, not logical processors. Hyperthreading does not double the count, and disabling cores in firmware does not reduce it unless done in a supported, documented way. You license the physical cores present on each populated CPU, full stop.

The three counting rules

Three rules combine to set your licensed quantity. Miss any one and your quote will surprise you.

The 16-core CPU minimum penalizes low-core processors: an 8-core CPU is billed as 16, a 100 percent overpay on that socket. The 72-core order minimum penalizes small estates: a deployment that physically totals 48 cores still pays for 72. Both rules stack, so a small cluster of low-core hosts can pay nearly double its physical core count before any discount applies.

Calculating your real core count

The calculation is mechanical once you have the hardware inventory. For each host, take the higher of actual cores per CPU or 16, multiply by the number of populated sockets, and sum across all hosts you intend to license. Then apply the 72-core order minimum to the total. The worked examples below show how quickly the minimums bite.

Multiply the billed core count by your per-core rate to get the subscription cost. At a VCF list near $350 per core, the 256-core example lists at roughly $89,600 per year; at a vSphere Foundation rate near $135 per core it lists near $34,560. The gap between bundles is why the VCF versus vSphere Foundation choice matters as much as the core count itself.

Host-design choices that lower the count

Three design moves reduce licensed cores. Consolidate onto fewer, denser hosts so every socket is fully used and no CPU rounds up to the 16-core floor. Standardize on CPUs whose physical core count is a clean multiple of your workload need, avoiding stranded capacity. And separate the workloads that truly need the full VCF stack from those that do not, licensing the latter on the cheaper vSphere Foundation bundle. Each move is a permanent reduction, not a one-time discount.

These choices interact with refresh cycles. The cheapest time to right-size for per-core licensing is at hardware refresh, when you can choose the CPU and host count deliberately. Aligning the refresh with the renewal, through a disciplined renewal plan, lets the new, leaner core count land in the next subscription term rather than the one after.

Per-core licensing in cloud and hosted environments

Per-core counting does not stop at your own data center. VMware running on hosted infrastructure, in a colocation facility, or through a managed service provider is still subject to the per-core rules, and the question of who holds the license, you or the provider, becomes a contract term rather than an afterthought. In a bring-your-own-license arrangement you license the physical cores of the hosts your workloads run on; in a provider-supplied model the cost is embedded in the service rate, often at a markup over the underlying per-core price.

The trap in hosted environments is the same soft-partitioning problem that affects other vendors: if your workloads can move across a larger pool of hosts than they currently occupy, the licensing scope can expand to the whole pool unless the configuration pins them. Confirm with any provider exactly which cores you are licensed for and how mobility is bounded, because an unbounded cluster in a hosted environment can multiply the licensed count well beyond the cores you actually use.

Public cloud VMware services follow their own commercial models, blending the per-core software cost into a consumption rate. When evaluating these, separate the software licensing component from the infrastructure component so you can compare it against an on-premise per-core cost and against the destination platforms in an exit analysis. The right comparison is total cost per workload, not headline per-core rate, because the surrounding infrastructure cost differs sharply between models.

Tracking cores through hardware refresh

The licensed core count is not static; it changes every time you refresh hardware. A refresh that moves from older, lower-core CPUs to modern high-core-count processors can increase the licensed count even at equal or lower host count, because per-core licensing scales with cores rather than sockets. This is the inverse of the old per-socket logic, under which dense CPUs reduced license cost, and teams that have not internalized the change are repeatedly surprised at refresh.

Plan the refresh and the licensing together. The goal at refresh is the host configuration that delivers the needed capacity at the lowest billed core count, which usually means fewer, fully populated hosts rather than many partially used ones. Model two or three candidate configurations against the per-core rate before ordering hardware, because the CPU choice is effectively a multi-year licensing commitment, detailed alongside the rates in our subscription pricing reference.

Keep a current core-count record as part of asset management. An accurate, maintained inventory of physical cores per host is the foundation for every quote, true-up, and renewal, and it is the first thing an audit will test. Estates that cannot quickly produce an authoritative core count negotiate from weakness and carry audit risk, while those that maintain it negotiate from evidence.

Documenting cores for audit readiness

Per-core licensing makes the physical core count the single most audited number in a VMware estate, so the record of it must be authoritative and current. An audit will reconcile the cores you have deployed against the cores you have licensed, and any gap becomes a finding. The estates that come through cleanly are the ones that maintain a live inventory of every host, its CPU model, its physical core count, and the license that covers it, updated at every hardware change rather than reconstructed under audit pressure.

Keep the evidence a vendor would ask for. That means hardware records that show physical cores per socket, deployment records that show which hosts run licensed software, and the entitlement records that show what you bought. When these three reconcile, an audit is a formality; when they do not, the burden falls on you to prove compliance after the fact, which is slower and weaker. Our audit defense practice builds this reconciliation in advance so an estate is audit-ready before any notice arrives.

Treat configuration changes as licensing events. Enabling a host, adding a node to a cluster, or refreshing onto higher-core CPUs all change the licensed quantity, and each should trigger an inventory update. The discipline is light when it is continuous and heavy when it is deferred, and it is the same record that anchors every quote and renewal from a position of evidence rather than estimate.

A final practical point: the per-core model rewards measurement over assumption. Estates that meter their actual CPU utilization often find that a meaningful share of licensed cores sit idle, carrying cost without carrying workload. That idle capacity is recoverable through consolidation at the next refresh, and identifying it is the same exercise that produces an accurate core count for negotiation. The number you measure is the number you can defend, and the number you can defend is the number you can reduce.

Carry the core-count discipline across the whole estate, including the environments that are easy to forget. Test, development, disaster-recovery, and management clusters all consume licensed cores under the same rules as production, and they are where untracked growth tends to hide. Bringing them into the same inventory and the same right-sizing review as production is frequently where the quickest reductions are found, because non-production estates are the least scrutinized and the most over-provisioned.

Common questions

Does hyperthreading affect the core count?

No. VMware per-core licensing counts physical cores, not logical processors. Hyperthreading does not change the number you license.

What is the minimum number of cores I must license?

Each populated CPU is billed at a minimum of 16 cores, and new orders since April 2025 carry a 72-core minimum total. A small deployment below these thresholds still pays for them.

Can I reduce cores by disabling them in firmware?

Only through supported, documented configurations, and even then the CPU minimum applies. In practice the reliable way to lower the count is host consolidation onto fewer, denser servers, not core disabling.

How do I calculate my licensed cores?

For each host, take the higher of actual cores per CPU or 16, multiply by populated sockets, sum across all hosts, then apply the 72-core order minimum to the total. Multiply by your per-core rate for the cost.