VMware vSphere Foundation licensing in 2026. Fix the core count before you lock the term.

VVF bills every physical core, with a 16 core floor per processor. A multi year term holds the rate and the core count together, so consolidate first and commit to the smaller number.

How does VMware vSphere Foundation licensing work in 2026?

VMware vSphere Foundation (VVF) is licensed per physical core on subscription, with a minimum of 16 cores for every processor. Sockets and virtual machines play no part in the count. There is no perpetual option, only annual or multi year terms, and the committed core count drives the bill.

VVF is the Broadcom bundle that packages vSphere with vCenter and a defined set of management tools. It sits below VMware Cloud Foundation (VCF) in scope and in price per core. Every discount, term and bundle decision multiplies against the core count.

What is included in vSphere Foundation?

Broadcom's current VVF documentation lists five components. Check them against what you run before you accept a VCF quote.

• vSphere Enterprise Plus. The top hypervisor edition, with DRS and vMotion.
• vCenter Standard. The program terms grant one instance per VVF subscription.
• vSphere Kubernetes Service. The Kubernetes runtime formerly branded Tanzu Kubernetes Grid.
• VCF Operations. Monitoring, plus VCF Operations for logs and diagnostics, the components previously sold as Aria Suite Standard.
• vSAN. 0.25 TiB per licensed core, with more available through the vSAN Add-on.

NSX networking, VCF Automation and HCX migration are not in VVF. If your teams do not use them at scale, most of the bundle question is already answered.

How does the 16 core minimum change the bill?

A processor with fewer than 16 cores is billed as if it had 16. A host with two 8 core CPUs has 16 physical cores and bills 32, which doubles its cost per unit of work. A host with two 12 core CPUs has 24 physical cores and bills 32, a third more than it contains.

Disabling cores does not help. The VVF program documentation requires every core on the server to be licensed, including cores deactivated in the BIOS. The only ways to reduce the count are fewer hosts or different processors.

What does a multi year VVF commitment lock in?

A multi year term locks two numbers: the per core rate and the quantity of cores that rate applies to. Most buyers negotiate the first and accept the second from the quote. Broadcom will hold a per core price for three or five years in exchange for the certainty, and for a stable environment that is a fair trade.

The problem is the quantity. A subscription has no mechanism to hand cores back mid term, so the count you sign is the count you pay for until expiry. If the quote came from a raw hypervisor export, you have bought a good rate on hardware you meant to decommission.

What happens if your core count falls during the term?

In most Broadcom terms, nothing happens to the invoice. The commitment covers a quantity as well as a rate, and retired hosts stay on the bill until expiry. Ask the question before you sign and get the answer written into the order, because it decides whether funding consolidation during the term makes financial sense.

Why we advise against signing the longest term first

The common advice for Broadcom renewals is to sign the longest term on offer, as early as possible, to shelter from the next price rise. We disagree whenever a consolidation is planned or overdue. Locking the rate early also locks the count early, and across our transition renewals the count was where the avoidable spend sat.

The better course is to scrub and consolidate first, then take the multi year rate on the resulting number. If the renewal date arrives before that work is done, sign one year at a count you can defend host by host. Compare annual and multi year offers at the same core count to see what the term itself is worth.

The rate is the number everyone negotiates. The core count underneath it is the number that decides the bill for the whole term.

What did VVF renewals look like during the Broadcom transition?

Across roughly 25 to 40 VMware environments we benchmarked through the Broadcom transition in 2024 to 2025, the per core model overturned the assumptions buyers brought from the per socket era. Three patterns recurred, and they compounded when they appeared together.

• Core inflation. 10 to 25 percent of licensed cores sat on hosts that a consolidation pass could have retired before the count was fixed. Those environments grew under per socket licensing, when core count carried no price and there was no reason to separate hosts carrying workload from hosts that merely existed.
• Minimum drag. The 16 core floor raised the effective rate on low core CPUs, which were also the hosts a consolidation would remove first. The cores most worth retiring were the ones costing the most per unit of work.
• Bundle mismatch. Customers bought VCF for features used on a fraction of their infrastructure, then paid the full bundle rate across every licensed core, including cores due for retirement.

Each of these can be fixed on its own. When all three are signed into a three to five year term, the bundle premium is charged on inflated cores, and some of those inflated cores are floor cores that do not physically exist.

The shift to subscription made this a recurring issue. Perpetual licenses with optional support were a sunk cost, and an oversized count cost little after purchase. Under subscription, every surplus core is paid again each year, so right sizing the count stopped being a one time exercise.

How much does signing before consolidation cost?

On a mid sized environment, signing first can cost more than any term discount returns. Say you run 40 dual socket hosts. Thirty carry two 24 core CPUs, so 48 cores each and 1,440 cores in total. Ten older hosts carry two 10 core CPUs: 200 physical cores that bill as 320 because of the minimum.

The quote counts 1,760 cores. A scrub shows 3 of the older hosts carry no production workload, and the other 7 can move onto the larger hosts, which have the headroom. Retiring all 10 removes 320 billed cores, about 18 percent of the quote, and 120 of those never existed as silicon.

The discounted term on the unscrubbed count still costs $21,600 a year more than the undiscounted scrubbed count. Doing both in the right order saves $129,600 over three years against the discount alone.

The worst case is signing at 1,760 and retiring the hosts six months into a three year term. You then pay for 320 cores on switched off hardware for 30 months, which is $120,000 at the illustrative rate with nothing running on it.

How do you check your own VVF core count?

Run Broadcom's own counting script, then match every host in its output to the workload it carries. The quote will use the same data, so see it first.

• Broadcom KB 313548. Publishes the FoundationCoreAndTiBUsage.psm1 PowerCLI module, and a multi vCenter version, which report licensable cores and vSAN TiB per host.
• RVTools vHost tab. Lists CPU count and cores per CPU per host, which is the quickest way to find processors under 16 cores.
• VCF Operations. Host and cluster capacity views show where installed hardware runs well ahead of demand.
• Your CMDB. Shows which hosts are due for refresh or were kept as spares.

Sort the host list into three groups: carrying production workload, candidates for consolidation, and idle. Only the first group belongs in the committed count once the consolidation is done. Our per core subscription calculator and the core licensing explainer help with the counting rules.

Which counting mistakes cost the most?

• Keeping low core hosts for redundancy. An 8 core CPU bills at 16, so two small hosts often cost more than one dense host with the same failover headroom.
• Counting with cores switched off. KB 313548 warns that cores disabled in the BIOS make the script undercount. The program terms license those cores anyway, so an order built on that output becomes a finding at the next compliance check.
• Carrying standby and lab hosts into the order. A raw export includes them, and each is billed for every year of the term.
• Forgetting the vSAN entitlement. Fewer cores means less included vSAN capacity. In the example above, 1,760 cores carry 440 TiB and 1,440 cores carry 360 TiB, so check claimed capacity before you retire vSAN hosts.
• Missing the compliance report. VVF requires a usage report 180 days after the license is registered and every 180 days after that. A missed report can degrade the management plane and suspend support.

When is vSphere Foundation enough instead of VCF?

VVF is enough when your measured feature use sits inside its scope. Decide component by component, using what your teams run today. License VCF only on clusters that need NSX, VCF Automation or HCX, or where the larger vSAN allowance in VCF costs less than buying the vSAN Add-on for VVF.

The pattern we saw most was the reverse: VCF bought across every core to cover features used on a fraction of the infrastructure. The full comparison of both bundles is in VCF against vSphere Foundation, and the VCF and VVF comparison calculator prices both at your own count.

How does the decision change for a small cluster and a large fleet?

• A small cluster. The minimum dominates. Three hosts with a single 8 core CPU each bill 48 cores for 24 physical ones, so moving to 16 core processors doubles capacity for the same bill. Ask the reseller to confirm in writing that no per order minimum applies to the quote. VCF is rarely justified at this size.
• A large fleet of several hundred hosts. Several hardware generations usually run side by side, and idle hosts hide in clusters without a clear owner. Scrub cluster by cluster, and make the bundle decision for each cluster separately.

What will the Broadcom account team say, and how should you answer?

Expect pressure to sign today's count on the longest term. These lines are typical, with replies that keep the count open.

• "The multi year rate is only available this quarter." Ask for that rate quoted on the post consolidation count. If the timing is fixed, request a one year term at the scrubbed count instead.
• "The count comes from your own vCenter data." Agree, and supply the KB 313548 output with the retired and idle hosts marked. The order should reflect the hosts you will run at the start of the term.
• "You will want VCF for the roadmap." Ask which VCF components the roadmap needs and on which clusters. Price VCF there and VVF elsewhere.
• "You can reduce at renewal." Renewal may be five years away. Ask for a reduction right tied to a named hardware refresh, or a shorter first term.

Which contract terms should you ask for before signing?

Ask for terms that tie the committed count to the hosts you run and say what happens when that changes. Broadcom does not grant these by default, so request them early.

1. A host schedule attached to the order. It records which hosts the count covers, so an audit or renewal starts from an agreed baseline.
2. A written mid term reduction position. Even a limited right, such as a reduction at a named refresh date, tells you what a falling count is worth.
3. A price hold on added cores. Cores added during the term should bill at the committed rate.
4. A renewal price cap. A cap on the rate at the next renewal protects the discount you negotiated. Our note on price cap negotiation covers the wording.
5. Bundle split by cluster. Confirmation that VVF and VCF can sit in the same agreement on different clusters.

When should each step happen before a VVF renewal?

Start about a year out. A consolidation pass usually takes a quarter of engineering work, and it has to finish before the quote is final.

The point in time cost picture, which licenses the cores you run rather than the cores you own, is in the 2026 cost breakdown. Negotiation specifics for this bundle are in our vSphere Foundation negotiation guide, and the wider library is in the Broadcom practice hub.

What to do next

1. Export the core inventory. Reconcile it against hosts carrying VMware workload, separating populated cores from working ones.
2. Run the consolidation pass before the quote. Target low core CPUs first, because they carry both the minimum drag and the strongest retirement case.
3. Decide VVF against VCF on measured feature use. Go component by component and cluster by cluster, and skip the bundle that covers every eventuality.
4. Model the multi year rate on the post consolidation count. Compare it with an annual term at the same number.
5. Check vSAN capacity after consolidation. Confirm the smaller core count still covers the capacity your clusters claim.
6. Get the mid term reduction position in writing before signing. The Broadcom practice runs the scrub and the negotiation with you.

Frequently asked questions