VMware VCF licensing explained: per-core minimums and what they mean for your budget

Broadcom's VMware licensing math is no longer socket math. For VMware Cloud Foundation, the number that matters is physical CPU cores, then the minimum rules get applied on top. That sounds like a small accounting change until a 3-host cluster with 48 real cores turns into a 72-core quote.

I would not treat any VCF quote as complete until the core count has been rebuilt from hardware inventory. A renewal spreadsheet that still says "6 sockets" is missing the thing Broadcom now charges for.

This article uses the latest licensing numbers in the site canonical facts file as of July 2026. The commercial model remains subscription-based and counted per physical core.

the numbers that drive the quote

Broadcom's own KB 313548 says VCF and VMware vSphere Foundation core licensing is based on the total number of physical CPU cores across all ESXi hosts being licensed. It also states the 16-core rule directly: each physical CPU must be licensed for at least 16 physical cores, even when the processor has fewer than 16.

That means the licensing formula starts at the host, not the cluster:

Billable cores per host = max(actual physical cores, physical CPU sockets x 16)

For a host with one 8-core CPU, the billable count is 16. For a host with two 12-core CPUs, the real count is 24 but the billable count is 32. For a host with two 24-core CPUs, the billable count is 48 because each CPU is already above the floor.

Canonical pricing puts VCF at $350 per core per year at list. I would use $350 for worst-case budget modeling unless a reseller has provided a written discount. Discounts that appear in one renewal do not mean the same rate appears in the next term.

Using the list number:

That table does not include support uplift, add-ons, partner services, taxes, or any term discount. It is list math only.

the 16-core floor is not a footnote

The 16-core-per-CPU rule hurts small hosts and older dual-socket systems. It also changes hardware refresh planning.

A single-socket 16-core server and a single-socket 8-core server both license as 16 cores. If the workload can run on the 16-core part, the 8-core part saves no licensing money under VCF. It may still save hardware cost or power, but it does not reduce the VCF subscription line.

Dual-socket low-core hosts are worse. A two-socket server with 10-core CPUs has 20 real cores but bills as 32. A two-socket server with 12-core CPUs has 24 real cores and also bills as 32. In a 4-host cluster, that is 128 billable cores even though the estate may have only 80 to 96 real cores.

This is where I have seen bad renewal data start. Someone exports sockets from vCenter, multiplies by a rough old per-socket number, then compares that to a Broadcom per-core quote. The comparison is wrong twice. The old metric is gone for new subscription purchases, and the 16-core floor can add cores that are not physically installed.

Use PowerCLI to pull the data from vCenter:

Connect-VIServer -Server vcenter.example.com

Get-VMHost | Sort-Object Name | ForEach-Object {
    $view = $_ | Get-View
    $sockets = $view.Hardware.CpuInfo.NumCpuPackages
    $cores = $view.Hardware.CpuInfo.NumCpuCores
    $billable = [math]::Max($cores, $sockets * 16)

    [PSCustomObject]@{
        Host = $_.Name
        Sockets = $sockets
        PhysicalCores = $cores
        BillableCores = $billable
    }
} | Format-Table -AutoSize

Then total it:

$total = Get-VMHost | ForEach-Object {
    $view = $_ | Get-View
    $sockets = $view.Hardware.CpuInfo.NumCpuPackages
    $cores = $view.Hardware.CpuInfo.NumCpuCores
    [math]::Max($cores, $sockets * 16)
} | Measure-Object -Sum

"Billable cores before any order floor: $($total.Sum)"
'VCF list budget at $350/core/year: {0:N0}' -f ($total.Sum * 350)

Do not use Windows WMI or CIM queries for ESXi hosts. ESXi is not Windows. The data is already in the vSphere API.

the 72-core order problem is messy

Broadcom introduced a 72-core per-order minimum in April 2025. After backlash, it was partially reversed for some existing renewals, but it still applies to new orders, subscription transitions, and tier changes. Treat reseller quotes below 72 cores as something to verify in writing.

Those statements are not identical, and that matters. Public documentation and reseller behavior have not lined up cleanly across every region, partner, and transaction type.

For budgeting, I would model two numbers for any small environment:

Scenario A: total billable cores after 16-core CPU floor
Scenario B: max(total billable cores, 72)

A 3-host cluster with one 16-core CPU per host has 48 billable cores after the 16-core CPU rule. At VCF list, that is $16,800 per year. If a 72-core order floor is applied, the same cluster becomes $25,200 per year. That is an extra $8,400 per year for cores that do not exist in the rack.

A 2-host edge cluster with one 12-core CPU per host has 24 real cores, 32 billable cores after the CPU floor, and potentially 72 cores if the order floor appears. At $350 per core per year, that range is $11,200 to $25,200 per year.

Ask the reseller to state the rule in writing for the exact transaction:

Does this quote enforce a 72-core minimum?
Is that minimum per order, per site, per product, or per ELA?
Does it apply to renewals, new subscriptions, tier changes, or all three?
If the quote is below 72 cores, will Broadcom accept the order?

If the answer is verbal, it is not enough for budget approval. The CFO will see the invoice, not the call notes.

VCF versus VVF changes the storage math

VCF is not only vSphere. It bundles the larger private cloud stack, including vSphere, vSAN, NSX, Aria components, SDDC Manager, and related lifecycle tooling. The licensing decision should include whether those components are deployed or planned.

The vSAN entitlement is different between VCF and VVF. Broadcom KB 313548 states VCF provides 1 TiB of vSAN entitlement for each VCF core purchased. The same KB states VVF provides 0.25 TiB of vSAN entitlement for each VVF core purchased.

On 96 licensed cores:

That does not mean every shop should buy VCF for storage. It means a vSAN-heavy environment can have a different answer from a vSphere-only cluster on an external array. A small cluster booting VMs from Fibre Channel or NFS may be paying for storage and networking features it will not run.

Raw vSAN capacity matters here, not usable capacity after failures-to-tolerate policy overhead. Broadcom's KB describes vSAN capacity licensing as total raw physical storage in TiB contributed by hosts to vSAN clusters. If a cluster has 120 TiB raw and only 96 TiB is entitled by the core subscription, the gap has to be handled with additional vSAN capacity licensing.

budget examples that expose the trap

Here are three budget models using VCF list pricing at $350 per core per year. They are not quotes. They are arithmetic checks before quote review.

The edge example is easy to underestimate. Two hosts with two 8-core CPUs each have only 32 real cores across the site, but the 16-core-per-CPU floor doubles the licensing count to 64. If a 72-core order floor is enforced, the cost rises again to $25,200 per year.

The dense cluster has the opposite issue. The 16-core floor does nothing because the CPUs are far above 16 cores. The bill is large because the actual core count is large. This is where old "per socket" thinking breaks hardest: two sockets can now mean 32 cores, 64 cores, 128 cores, or more.

hardware choices now affect software spend

Server design now has a direct subscription cost effect. Before buying refresh hardware, run the licensing math against the CPU SKUs.

A 2-socket host with two 16-core CPUs and a 1-socket host with one 32-core CPU both license as 32 cores. The single-socket design may lose memory channels, PCIe lanes, or vendor-supported configurations, so the licensing answer cannot be the only answer. But if both designs meet the workload requirement, the VMware bill is identical.

A 2-socket host with two 8-core CPUs is different. It licenses as 32 cores even though it has 16 real cores. If that host exists because of an older purchasing pattern, it may be a bad fit for VCF subscription economics.

For lab planning or admin refresh work, I would separate training gear from production licensing decisions. A VMware vSphere 8 administration book may help staff get through the new operational model, but it will not answer the commercial question. For home labs, used Dell PowerEdge servers can be useful, but do not model a production VCF budget from random lab hardware with old low-core CPUs.

what to verify before signing

Before approving a VCF renewal or migration quote, I would ask for these items in writing:

• Product bundle: VCF, VVF, vSphere Standard, or another SKU.
• Term: 1, 3, or 5 years.
• Per-core price before and after discount.
• Physical hosts included in the license count.
• Core count per host and the 16-core-per-CPU calculation.
• Whether any 72-core minimum is applied.
• vSAN raw TiB included and any add-on capacity required.
• Upgrade rights for VCF 9.1 and later releases.
• Support level and renewal date.
• True-up process for adding hosts or replacing CPUs mid-term.

The risky quote is the one that only shows a total. A total without core math cannot be checked against vCenter inventory, cannot be reconciled against a hardware refresh plan, and cannot show whether the reseller applied a floor.

sources

• Broadcom KB 313548, "Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN" - 16-core-per-CPU rule, VCF 1 TiB/core vSAN entitlement, VVF 0.25 TiB/core vSAN entitlement.
• Broadcom TechDocs, "VMware Cloud Foundation 9.1 Release Notes" - VCF 9.1, May 12, 2026, build 25377994.
• Atonement Licensing, "VMware Cloud Foundation Licensing 2026: Per-Core Rules" - VCF list price around $350/core/year and 2026 discount observations.
• Licenseware, "VMware Walks Back Controversial Licensing Change After Industry Backlash" - May 2025 reporting on the disputed 72-core minimum and rollback.