This is the mechanics page. If you want the story of what Broadcom changed and what it did to renewal prices, read VMware licensing changes first, then come back here. That page covers what moved. This one covers how the thing you are buying now actually works, so you can read your own transaction document and know what you agreed to.
Who this page is for
You have a quote, a renewal notice, or a contract in front of you and you want to understand the model behind it rather than argue about the total. You may be trying to work out why your core count is higher than your hardware, whether the bundle you are quoted is the one you need, or what happens if you add hosts halfway through a term. If your question is the size of the increase rather than the structure, start with why your renewal went up.
The license metric: physical cores, with a floor
The metric is the physical core. Not the socket, not the virtual machine, not the amount of RAM. Broadcom's specific program documentation for vSphere Standard, published February 2026, states it plainly: the software is licensed on a per core metric with a minimum licensing requirement of 16 cores per processor. The same 16 core floor applies to VMware Cloud Foundation and vSphere Foundation, and Broadcom's core counting guidance says so in the same words.
Two consequences follow, and both cost money.
- Small CPUs are rounded up. A processor with 8 cores is licensed as 16. A processor with 12 cores is licensed as 16. A processor with 24 cores is licensed as 24. The floor is per processor, not per server and not per estate, so a host with two small CPUs pays the penalty twice.
- Cores you disabled still count. The vSphere Standard program documentation says every core on the server where the software is installed must be licensed, including cores deactivated by the BIOS. Turning cores off in firmware is not a licensing lever. Broadcom's own core counting script also warns that disabled cores make its results inaccurate, so a count taken from a host with cores switched off will understate what you owe.
Worked example: two ways to run 200 virtual machines
This is the part that surprises people. The workload is identical in every row below. The licensed footprint is not, and the estate with the fewest physical cores is the one that bills the most.
| 200 VM estate | Hosts and CPUs | Physical cores | Billable cores | Why |
|---|---|---|---|---|
| Estate A Older, wider |
12 hosts, 2 CPUs each, 10 cores per CPU | 240 | 384 | All 24 processors are under the floor, so each one is charged at 16 cores |
| Estate B Fewer, denser |
6 hosts, 2 CPUs each, 24 cores per CPU | 288 | 288 | Every processor is already above the floor, so actual cores are charged |
| Estate C Exactly at the line |
8 hosts, 2 CPUs each, 16 cores per CPU | 256 | 256 | Sixteen cores per processor is the floor and the actual count at the same time |
Estate A holds 48 fewer physical cores than Estate B and is billed for 96 more. That is a third more licensing for the same 200 virtual machines, caused entirely by the shape of the hardware underneath them. It is also why a refresh onto denser CPUs can lower a license bill even though it raises the raw core count, and why counting your own processors before the quote arrives is worth an afternoon.
To put your contracted rate against those numbers and see the three year picture next to the alternatives, use the cost calculator.
The three bundles, and what each one entitles you to
Thousands of individual SKUs were consolidated into a small set of per core bundles. Which one you are quoted matters more than any discount, because the bundles carry very different entitlements at very different rates.
| Bundle | What it is | Published vSAN entitlement | Fits |
|---|---|---|---|
| VMware Cloud Foundation VCF |
The full private cloud platform: vSphere plus the wider stack, including vSAN, NSX, operations and automation | 1 TiB of vSAN for each licensed VCF core | Organizations genuinely running NSX and vSAN at scale |
| vSphere Foundation VVF |
The virtualization tier: vSphere focused, with operations capability and a smaller feature footprint | 0.25 TiB of vSAN for each licensed VVF core, rounded up to the next TiB | Estates that ran vSphere Enterprise Plus and do not need the full stack |
| vSphere Standard | The smallest current subscription. Per core, same 16 core floor, with vCenter Server entitled as a single instance | Not included | Straightforward virtualization estates with no software defined storage or networking requirement |
Exact components change between product generations and contracts, so confirm the bill of materials, the entitlements and the support level against your own quote rather than a public summary. The point of the table is the shape of the choice, not a specification you can hold a seller to.
Four clauses that decide what you can actually do
These come from Broadcom's specific program documentation for vSphere Standard, dated February 2026. They are the sort of thing nobody reads until it blocks a project.
- You cannot run it on cloud services. The documentation prohibits deploying the software on infrastructure a third party markets or makes available as a service. On premises kit in your own data center or a colocation facility is carved out, provided the third party has no access to the software and performs no services on it. So bringing your own vSphere Standard license to a public cloud is not on the table, and a managed provider arrangement has to be licensed by the provider rather than by you.
- You cannot host other people on it. Use of the software for hosting or for the benefit of any third party is prohibited, except for what the documentation calls a deemed internal purpose application: your own application, delivered to your own users, where those users cannot access or benefit from the software's features. If you deliver IT services to clients, read that definition carefully before assuming you are covered.
- Support comes with the license and does not travel. The license includes an entitlement to support and maintenance services, and that entitlement may only be used for the software it was bought for. It cannot be applied to other software, including former components of the bundle that you once licensed separately. If a product left your bundle at renewal, its support left with it.
- Every core must be licensed, including the ones you switched off. Covered above, and worth repeating because it is the single most common misreading of the metric.
If you still hold perpetual licenses
Perpetual licenses were not revoked. The software keeps running and you keep the right to run it. What ended is the ability to buy new ones and the ability to renew support and subscription on them, announced in December 2023.
The upgrade right is narrower than most owners expect. Broadcom's vSphere Standard documentation states that customers holding perpetual licenses to the legacy software of the same name, with an active subscription to support and subscription services, may upgrade to version 8.x only, and only until the earlier of their support end date or the end of support for 8.x itself. There is no entitlement to any version above 8.x. So a perpetual estate has a fixed ceiling and a fixed clock, and both are already visible.
What that means in practice: running on unsupported VMware is a decision with a date attached, not an indefinite holding pattern. Patches stop, compliance assessors ask, and returning to a subscription after a lapse can carry back dated fees. The dates themselves are in the VMware end of life guide, and the honest version of how long you can sit still is in the licensing changes guide.
What a subscription term actually commits you to
A perpetual license made the software an asset and support an annual choice. A subscription makes both a single recurring commitment, and that changes the questions you should be asking at signature.
- Term length is a leverage decision, not just a price one. A multi year term buys a discount and gives up the ability to price alternatives until it ends. A one year bridge costs that discount and keeps the option open. Which is right depends on whether you already know what the alternatives cost.
- Anniversary and auto renewal. Find the expiry date and any automatic renewal language in your own transaction document, and diary it at least six months out. Leverage disappears in the final thirty days.
- Adding capacity mid term. If you add hosts or processors during a term, you are adding licenses. Ask, before you sign, how additions are priced, whether they align to the existing end date, and at what rate. Broadcom's published program documentation does not set those mechanics; your transaction document does, which is exactly why it is worth asking while you still have a negotiation to use.
- Reconciliation at renewal. The count that renews is the count Broadcom believes you are running. Reconcile it against your own inventory before the renewal is issued, not after.
The levers available once the quote is in hand, ranked by what each one moves, are on the renewal cost reduction page.
Common mistakes reading the model
- Counting virtual machines. VM count is not a licensing input. Two identical 200 VM estates can differ by a third in billable cores.
- Disabling cores in the BIOS to shrink the bill. The documentation licenses them anyway, and it breaks the count.
- Assuming the quoted bundle is the required bundle. Bundle assignment is a quote input, and correcting it moves more money than any discount percentage.
- Treating a public per core price as your price. Your rate is contractual. There is no list price substitute.
- Planning to move your own licenses into a hosted environment. Check the cloud services restriction first. The licensing usually has to sit with the provider.
- Expecting perpetual licenses to keep upgrading. The upgrade right stops at 8.x and expires with your support end date.
What to do next
- Count physical processors and cores per processor across every licensed host, then apply the 16 core floor to each processor.
- Compare that number to the core count on your quote and ask about any gap.
- Identify the bundle you are quoted and list which of its components you actually run.
- Read the cloud services and hosting clauses if any part of your estate is provider hosted or serves third parties.
- Find your term end date and any auto renewal language, and ask how mid term additions are priced.
- Price at least one alternative before the negotiation, so the corrections above have something standing behind them.
Sources: Broadcom, VMware vSphere Standard Specific Program Documentation, February 2026, for the license metric, the 16 core minimum per processor, BIOS deactivated cores, the vCenter Server instance entitlement, the cloud services and hosting restrictions, the support entitlement, and the legacy perpetual upgrade limit. Broadcom knowledge base article 313548, counting cores for VMware Cloud Foundation and vSphere Foundation, for the 16 core minimum and the vSAN entitlements of 1 TiB per VCF core and 0.25 TiB per VVF core. Checked September 9, 2026. No per core price is published here because pricing is contractual.
VMware subscription licensing FAQ
How is VMware licensed now?
As an annual or multi year subscription, metered per physical CPU core, with a minimum of 16 cores charged for each physical processor. Every core on a licensed server must be licensed, including cores deactivated in the BIOS. Billable cores multiplied by your contracted per core rate gives the annual software price, before anything quoted separately.
Does the number of virtual machines affect VMware licensing cost?
No. The metric is physical cores, so the hardware underneath decides the bill. Two estates running the same 200 virtual machines can differ by a third in billable cores if one runs many small processors and the other runs fewer dense ones.
What is the difference between VCF, vSphere Foundation and vSphere Standard?
VMware Cloud Foundation is the full private cloud platform and carries 1 TiB of vSAN entitlement per licensed core. vSphere Foundation is the virtualization tier and carries 0.25 TiB per licensed core, rounded up. vSphere Standard is the smallest current subscription, with vCenter Server entitled as a single instance and no vSAN entitlement. Components vary by product generation and contract, so confirm against your own quote.
Can I still upgrade my perpetual VMware licenses?
Only within limits. Broadcom's vSphere Standard program documentation says holders of the legacy perpetual product with active support may upgrade to version 8.x, until the earlier of their support end date or the end of support for 8.x. There is no entitlement to any version above 8.x.
Can I run my own VMware subscription licenses in a cloud or at a hosting provider?
Generally not. The vSphere Standard documentation prohibits deploying the software on infrastructure that a third party markets or makes available as a service. Infrastructure in your own data center or a colocation facility is carved out, provided the third party neither accesses the software nor performs services on it. A managed VMware arrangement is normally licensed by the provider instead.