VMware’s Official Floor Is 16 Cores Per CPU, Not 72
You landed on this URL because it still says the VMware minimum jumped from 16 cores to 72. That is the query. It is not the public counting rule. Broadcom’s current VMware Cloud Foundation and vSphere Foundation docs license per core, with a minimum of 16 cores per physical CPU. An 8-core CPU consumes 16. The June 2026 VCF Software Product Description states the same floor, and that BIOS-deactivated cores still count. That is Broadcom’s own table, not a reseller slide.
That’s the problem.
This page originally split two minima: 16 cores per CPU as the product rule, and a 72-core per-product purchase threshold reported for 10 April 2025. The live copy still tells you that you must now buy 72 cores. That sentence is the stale part. Official public Broadcom pages fetched 29 August 2026 do not state a 72-core order minimum. Stay versus convert is the parent decision. How to apply the 16-core floor is VMware’s licensing model. This page is the March 2025 purchase-threshold rumor versus the public floor. Keep the URL. Stop teaching 72 cores as if Broadcom put it in the SPD.
What Broadcom’s public docs actually count
Quote the pages. Do not paraphrase them into a 72-core rule.
The VCF Software Product Description (June 2026) says:
Software is subscription software licensed on a per Core license metric with a minimum licensing requirement of 16 Cores per Processor.
The same SPD says each Core on the Server must be licensed, including Cores deactivated by the BIOS. The required number of Core licenses equals the number of Cores on the Server, subject to that 16-core-per-Processor minimum.
Broadcom’s licensing model (last updated 24 August 2026) says:
Most products have a minimum consumption rule of 16 cores per physical CPU. CPUs that have fewer than 16 cores consume 16 cores.
Primary licenses are VCF and vSphere Foundation, per core. Only ESX hosts consume primary capacity. You assign the primary license to a vCenter instance. Other components connected to that vCenter are licensed automatically. You no longer license NSX, HCX, or VCF Automation as separate components. VCF Edge is a different product with an 8-core-per-CPU minimum and deployment limits. Do not mix Edge with VCF.
Broadcom’s own worked table on that page:
| Number of ESX hosts | CPUs per host | Cores per CPU | Required license capacity |
|---|---|---|---|
| 1 | 1 | 8 | 16 |
| 2 | 2 | 8 | 64 |
| 2 | 2 | 16 | 64 |
| 2 | 2 | 24 | 96 |
One host, one CPU, eight cores requires 16 cores of capacity. Not 72.
KB 95927 (article 313548) is the counting article. It states the key rule:
You must license a minimum of 16 physical cores for each CPU (physical processor) in your ESXi hosts, even if a CPU has fewer than 16 cores.
The same KB works a three-host example: three hosts, one CPU each, eight cores per CPU. Customers must purchase 48 cores because the minimum is 16 cores per CPU. That is 48, not 72. Another KB line: Host A (2 CPUs x 8 cores) plus Host B (2 CPUs x 24 cores) converts to Host A at 2 x 16 plus Host B at 2 x 24, which is 80 cores to license. For larger estates Broadcom points at a License Counting PowerCLI tool. The vSphere Client capacity overview is not the bill. A host list that ignores deactivated cores is not the SPD count.
vSAN is included entitlement versus add-on. The same KB states VCF includes 1 TiB of vSAN per VCF core, and vSphere Foundation includes 0.25 TiB per VVF core, rounded up. Extra vSAN is an add-on in TiB. Do not invent a vSAN list price. The full metric, including VCF 9 reporting every 180 days and the 90 days after expiry, lives on Understanding VMware’s licensing model. This page is not a second metric hub.
Do not invent a VCF or VVF list price. Your number is the quote on this estate.
What the 72-core story was
Keep two objects separate. The 16-core-per-CPU product rule did not change. It is still the sentence in the SPD, the techdocs licensing model, and KB 95927.
The second object was a purchase threshold. This URL published on 27 March 2025 as a news item. The live copy taught that from 10 April 2025 you would have to buy a minimum of 72 cores per product, on top of the 16-core per-CPU floor, and that you could not mix VCF cores with vSphere Foundation cores to hit 72. It also taught a 20 percent late-renewal add-on versus list. That is how the slug still reads. People still search it. That is why the URL stays.
That 72-core VCF purchase threshold is not in the June 2026 SPD, not on the licensing-model page, and not in KB 95927. Those pages count consumption: physical cores on ESX hosts, then the 16-core CPU floor. They do not say “buy 72 cores of each product even if you run fewer.”
The 72-core line was a channel story. CRN published an Arrow memo to solution providers: “Starting April 10, the minimum number of cores required for VMware licenses will increase substantially from 16 to 72 cores per command line.” The same memo said an 8-core single-processor server would be licensed at 72 cores, and that late renewals would cost an extra 20 percent of the first-year subscription, applied retroactively. CRN said it asked Broadcom and Arrow for comment. Neither had responded by publication time. That memo is not the SPD.
There was industry controversy in early 2025. Coverage treated a 72-core purchase minimum as incoming, then as unofficial or walked back. Heise iX reported on 10 April 2025 that a distributor confirmed companies could still buy from 16 cores, and that Broadcom had issued a revised reseller price list. Asked by iX, a Broadcom spokesperson said Broadcom had never announced a price change, and that the 16-core minimum set in December 2023 had not changed. Licenseware’s own follow-up, VMware walks back controversial licensing change (8 May 2025), is the sister post. Leave that URL.
A channel quantity on a quote is commercial paper on that quote. It is not a reason to recast every CPU as 72 cores. If a quote in front of you still shows 72 as a purchase quantity, or a 20 percent late-renewal line, read that quote. Count the estate with the 16-core floor. Put the quote next to that count. Confirm on this estate. Do not brief a distributor memo as if it replaced KB 95927.
How the catalog became VCF and vSphere Foundation after close sits on the Broadcom VMware close spoke. Perpetual you already hold is a right to keep using a version. It is not a 72-core purchase rule, and it is not a right to buy more of that SKU.
Do not mix a Tanzu quantity with a VCF floor
When Broadcom writes “72-core” on a public knowledge article, read the SKU. KB 392545 (Tanzu Data end of availability, effective 4 May 2025) lists recommended replacement Tanzu Data products “with a 72-core minimum quantity”: Tanzu Data Suite V2, Tanzu Data Services V2, and Tanzu RabbitMQ. That is a Tanzu Data order quantity on those replacement SKUs. It is not the VCF or vSphere Foundation consumption floor. Do not take a Tanzu Data line and apply it to the ESX hosts you are pricing as Cloud Foundation.
Two objects on the same quote
Keep them separate.
- Consumption floor. Sixteen cores per physical CPU on ESX hosts for VCF and vSphere Foundation. Official. Quoted above. Worked table. SPD. KB 95927.
- Purchase quantity on a given order. Whatever the quote says, including any 72-core line a partner still prints, and any late-renewal add-on. That is that paper. It is not the public counting rule.
You cannot “meet 72” by mixing VCF and vSphere Foundation in any case, because they are different primary licenses. Capacity pools when the subscription is the same product, the same unit of measure, and the same Site ID. Licensing overview is the source for pooling. That is still not a 72-core floor.
Do not convert every small estate into a 72-core buy because this URL ranks. Count cores. Then read the quote.
What to have this week
Do this before the next VMware conversation. Produce a decision pack, not a reaction to a 2025 headline.
- Host times CPU times cores, after the 16-core floor. Physical cores on ESX hosts. BIOS-deactivated cores still count. One owner of the number.
- Product actually deployed versus SKU on the quote. VCF, vSphere Foundation, residual perpetual, or a suite name that is no longer primary.
- Any purchase-quantity line on the quote, including a 72-core partner line if it is still there, written next to the consumption count, not instead of it.
- Support end date, and who can still sell. Vendor, distributor, reseller, CSP: named, not assumed. Any late-renewal add-on on this paper, not a percentage copied from a 2025 memo.
- A stay, shrink, or convert cost on those cores. Renewal optimization if the term is walking in. Cost optimization if you are pricing stay versus leave.
Can a non-specialist brief the CIO in fifteen minutes from the pack you have today? If the answer is “we have to buy 72 cores because a post said so,” you do not have a VMware position. You have a rumor.
Picture your procurement director, sixty days out. Finance has this URL bookmarked. The quote walking in may still print 72. Neither is the SPD. The stay number is the VCF or vSphere Foundation quote on the cores you actually run after the 16-core floor. The leave number is not a rival’s list price.
The decision layer, not another VMware inventory
You already have discovery data, a CMDB full of VMware records, and a search result that still says 72 cores. The gap is not another inventory. The gap is turning that estate into a metric: cores after the 16-core floor, product actually deployed, any purchase-quantity line on the quote sitting next to that count, support end date, who can still transact. LICENSEWARE sits on the inventory and ITSM tools you already run. It is not a rip-and-replace SAM suite. It is a decision layer: what matters, why it matters now, what should happen next. Software Inventory Manager is the deployment file. License Lifecycle Manager is the renewal file. There is no VMware-specific app URL. Do not invent one.
If you are heading into a VMware renewal or a Cloud Foundation conversation and your current tools still need three weeks to turn a 72-core rumor into a per-core position, book an Audit Readiness Review. You can also start on the free plan and run the analysis on your own data.
Do not let the vendor frame this as “here is Cloud Foundation, and the minimum is 72.” Do not let your own side frame it as a processor perpetual model Broadcom no longer sells as the default, or as a 72-core law because this slug ranks. The right question is: which SKU, how many cores after the 16-core floor, what the quote actually requires as a purchase quantity, and what that costs on this estate. That is a data question, not a sales question.
The vendor will walk in with a number. The only question is whether you have yours first: current, defensible, and tied to the contract in front of you.
Sources
- VCF Software Product Description (June 2026), 16 Cores per Processor: https://ftpdocs.broadcom.com/cadocs/0/VCF_SPD_June2026.pdf
- VCF 9 licensing model (16-core CPU floor and worked host table, last updated 24 August 2026): https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/licensing/licensing-overview/licensing-model.html
- VCF 9 licensing overview (subscription files, primary licenses, pooling): https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/licensing/licensing-overview.html
- Broadcom KB 95927 / article 313548, counting cores and vSAN TiB: https://knowledge.broadcom.com/external/article?legacyId=95927
- VMware Cloud Foundation product page: https://www.vmware.com/products/cloud-infrastructure/vmware-cloud-foundation
- CRN, Arrow memo (“72 cores per command line” from 10 April 2025; 20 percent late-renewal line): https://www.crn.com/news/data-center/2025/broadcom-vmware-ups-minimum-core-purchase-substantially-levies-late-renewal-penalties
- Heise iX, 10 April 2025 walk-back (distributor confirmation, revised reseller price list, spokesperson): https://www.heise.de/news/Rueckzieher-bei-VMware-Unternehmen-koennen-weiterhin-16-Kerne-lizenzieren-10346897.html
- Broadcom KB 392545, Tanzu Data EOA and 72-core minimum quantity on replacement Tanzu Data SKUs: https://knowledge.broadcom.com/external/article/392545
- Sister post (Leave): https://beta.licenseware.io/vmware-walks-back-controversial-licensing-change-after-industry-backlash-denies-official-announcement/