Managing VMware Licensing Costs Under Broadcom -- Core Counts, Tier Selection, Cluster Design, and Renewal Tactics
VMware vSphere | Licensing | Audience: Infrastructure Architects, IT Directors, Procurement
Broadcom's acquisition of VMware in late 2023 produced the most disruptive licensing change the virtualization market has seen in a long time. Perpetual licenses are gone entirely. The product catalog went from 160-plus offerings down to four. Every physical core on every licensed host now counts toward your subscription. There's a 16-core minimum per CPU and a 20 percent penalty if you miss your renewal date. In April 2025, Broadcom attempted to introduce a 72-core minimum order but walked it back after industry backlash. It's off the table for now, but the intent was clear: Broadcom is optimizing for large enterprise customers and the minimum could return in a different form. Customers are reporting cost increases of 8x to 15x compared to what they were paying before the acquisition.
This article is about working within that reality as effectively as possible. Not speculation about what Broadcom might do next. Concrete decisions you can make right now about core count, tier selection, cluster design, and renewal timing that minimize what you're paying while keeping the infrastructure you need.
1. How the Per Core Model Works
The old per socket model counted physical CPU sockets regardless of how many cores were in each socket. The new per core model counts every physical core on every host you intend to license. Two rules make it more expensive than the raw core count suggests:
- 16-core minimum per CPU. If your server has a single socket CPU with 8 or 10 or 14 cores, Broadcom counts it as 16 cores. You pay for the full 16 regardless of what's physically there. A two socket server with two 8-core CPUs has 16 actual cores but gets counted as 32 cores because each socket hits the 16-core floor.
- 72-core minimum order was attempted and reversed. In April 2025, Broadcom tried to enforce a 72-core minimum purchase per product. The backlash was immediate, especially from SMBs and ROBO deployments, and Broadcom reversed it before it took effect. The current minimum remains 16 cores per CPU. The reversal was confirmed by distributors and reflected in updated price lists. Plan for 16-core minimums, but factor the 72-core attempt into your risk assessment for future renewals.
Core counting is based on all physical CPU cores on each host, with disabled cores still counting. Broadcom's official guidance is explicit: all physical CPU cores should be activated on each CPU when running the licensing count script. You can't disable cores in BIOS to reduce your count. If the cores are physically there, they count.
# Download the official script from Broadcom KB 313548 # Requires PowerCLI 13.3 or greater # Run against your vCenter to get accurate core counts # Connect to vCenter Connect-VIServer -Server vcenter.yourdomain.local # Import the module (path to downloaded script) Import-Module .\Get-FoundationCoreAndTiBUsage.ps1 # Count cores for vSphere Foundation (VVF) Get-FoundationCoreAndTiBUsage -DeploymentType VVF # Count cores for VMware Cloud Foundation (VCF) Get-FoundationCoreAndTiBUsage -DeploymentType VCF # Export results to CSV for renewal negotiations Get-FoundationCoreAndTiBUsage -DeploymentType VVF | Export-Csv "core-count-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation # The output shows per host actual cores, licensed cores (with 16-core minimum applied), # per cluster totals, and grand total required subscriptions
2. The Four Tiers: What You Actually Get
Broadcom consolidated VMware's product catalog into four active tiers. Essentials Plus was discontinued in October 2024 and replaced by vSphere Enterprise Plus. The current four tiers are listed below, but be aware that vSphere Standard went End of Sale in mid 2025, and vSphere 9 is only available through VVF or VCF. Standard and Enterprise Plus are effectively v8 only going forward. If you need vSphere 9 features, VVF is the entry point.
| Tier | Key Features Included | What's Missing vs Higher Tiers | Best For |
|---|---|---|---|
| vSphere Standard | vSphere, vCenter, vMotion, HA, basic resource management | No DRS, no Distributed Switch (VDS), no vSAN, no NSX, no Aria Operations | Small environments that only need VM hosting, live migration, and basic HA. No advanced networking or storage automation needed. |
| vSphere Foundation (VVF) | Everything in Standard plus DRS, Distributed Switch, vSAN (0.25 TiB per core), Aria Operations | No NSX, no Aria Automation or Orchestrator, no full Tanzu stack (includes Tanzu Kubernetes Grid for one supervisor cluster only) | Mid market production environments that need DRS, VDS, and vSAN but don't need full SDN or cloud automation. |
| vSphere Enterprise Plus | vSphere Enterprise Plus, vCenter Standard, DRS, Distributed Switch, VM encryption, Storage vMotion | No vSAN, no Aria Operations, no NSX, no Tanzu. No add on options available for this tier. | Organizations needing Enterprise Plus features like DRS and VM encryption but no vSAN and not ready for the full VVF bundle cost. |
| VMware Cloud Foundation (VCF) | Everything in VVF plus NSX, Aria Automation, Aria Orchestrator, SDDC Manager, full Tanzu, vSAN (1 TiB per core) | Nothing. This is the full stack. | Large enterprises, MSPs, and organizations running software defined networking or Kubernetes workloads. The price is significantly higher than VVF. |
The most common overspend pattern is paying for VCF when VVF covers everything the environment actually uses. NSX and full Tanzu are both powerful but most mid market environments have never deployed either. If your environment isn't using NSX and isn't running Kubernetes workloads beyond what VVF's single supervisor cluster Tanzu KG provides, VCF is buying features you're not consuming at a significant price premium. The second most common overspend is paying for VVF when Enterprise Plus covers everything you actually need. If you're not using vSAN and have no plans to, the bundle overhead in VVF may not be worth it.
3. Feature Audit: What Are You Actually Using?
Before your renewal negotiation, run a feature usage audit. The goal is to answer one question: does your environment use the features that justify the tier you're on? If it doesn't, you're a candidate for a lower tier.
Connect-VIServer -Server vcenter.yourdomain.local
# Check if Distributed vSwitches are in use (VVF/VCF feature)
$vds = Get-VDSwitch
Write-Host "Distributed vSwitches: $($vds.Count)"
$vds | Select-Object Name, NumPorts, @{N='Hosts';E={($_ | Get-VMHost).Count}}
# Check DRS configuration per cluster (VVF/VCF feature)
Get-Cluster | Select-Object Name, DrsEnabled, DrsAutomationLevel |
Format-Table -AutoSize
# Check vSAN clusters (VVF/VCF feature)
Get-Cluster | Where-Object { $_.VsanEnabled } |
Select-Object Name, @{N='vSANEnabled';E={'Yes'}} | Format-Table
# Check NSX deployment (VCF feature)
# NSX presence is detected by checking for NSX VIBs on hosts
Get-Cluster | ForEach-Object {
$cl = $_
$hosts = Get-VMHost -Location $cl
Write-Host "Cluster: $($cl.Name)"
$hosts | Select-Object Name, @{N='NSX';E={
(Get-EsxCli -VMHost $_ -V2).software.vib.list.Invoke() |
Where-Object { $_.Name -like '*nsx*' } | Measure-Object |
ForEach-Object { $_.Count -gt 0 }
}}
}
# Check for Tanzu workload clusters
# These show as 'vCLS' namespace VMs and Supervisor clusters
Get-VM | Where-Object { $_.Name -like 'vCLS*' } | Select-Object Name, Host
If DRS is disabled across all clusters, you don't need VVF for that feature. If you have no VDS deployments, no vSAN clusters, no NSX transport nodes, and no Tanzu supervisor clusters, you have Standard tier feature usage while potentially paying VVF or VCF pricing. That gap is the negotiating conversation with your account team before renewal.
4. Core Count Optimization: Host Sizing Decisions
The 16-core minimum per CPU means the worst case scenario for licensing cost per workload is a server with many sockets carrying low core CPUs. A four socket server with 8-core CPUs has 32 actual cores but gets counted as 64 licensed cores (4 sockets x 16-core floor). The same compute capacity in a two socket server with 16-core CPUs has 32 actual cores and 32 licensed cores. Same workload, half the licensing.
The principle is straightforward: fewer sockets with more cores per CPU reduces your licensed core count for the same compute capacity. When evaluating new server hardware, always calculate the licensed core count under Broadcom's model, not just the actual core count. A denser two socket server almost always wins over a four socket server for licensing purposes, even if the four socket server has lower per unit hardware cost.
| Server Config | Actual Cores | Licensed Cores (16-core min) | Licensing Penalty |
|---|---|---|---|
| 2 sockets x 8 cores | 16 | 32 | 2x |
| 2 sockets x 16 cores | 32 | 32 | None |
| 2 sockets x 24 cores | 48 | 48 | None |
| 4 sockets x 8 cores | 32 | 64 | 2x |
| 4 sockets x 16 cores | 64 | 64 | None |
| 2 sockets x 32 cores | 64 | 64 | None |
The sweet spot from a licensing perspective is two socket servers with 16 or more cores per CPU. At that configuration the 16-core floor doesn't add any overhead, and you're minimizing socket count while maximizing actual compute density. For new hardware purchases post Broadcom, two socket servers with modern high core count CPUs (AMD EPYC or Intel Xeon with 24-plus cores per socket) have a strong licensing cost advantage over multi socket configurations with older lower core CPUs.
5. Cluster Design Decisions That Affect Core Count
How you organize hosts into clusters affects which hosts need licensing and at what tier. Not every host in your environment necessarily needs to run the same tier.
- Separate production and non-production clusters. Dev and test environments don't need DRS, VDS, or vSAN. If they're in their own cluster, that cluster can run vSphere Standard while production runs VVF or VCF. You don't have to standardize on one tier across the entire estate. License each cluster at the tier the cluster actually needs.
- Right size HA admission control. Many environments over provision hosts specifically to satisfy HA admission control policy. Every over provisioned host adds to your licensed core count. Calculate the minimum host count needed for your HA tolerance and workload capacity before adding hosts for HA headroom.
- Consolidate small clusters. A cluster with three hosts running at 20 percent utilization needs to be consolidated before renewal. Three lightly loaded hosts contribute their full core count to your subscription. One or two appropriately sized hosts at higher utilization costs less to license and is no harder to manage.
- Decommission or repurpose dormant hosts. Hosts that are powered on but running zero or minimal VMs still count toward your licensed core total if they're connected to vCenter. Take them out of vCenter inventory before your renewal window closes.
6. The Renewal Conversation: Timing and Tactics
The 20 percent late renewal penalty is real. It applies retroactively from the anniversary date. Missing the renewal date doesn't just mean you pay 20 percent more from the moment you renew. It applies from the date your contract expired. Start the renewal conversation at least six months before the anniversary date, not 30 days before. You need time to run the core count audit, do the feature usage analysis, build your counter proposal, and negotiate before the deadline creates urgency that works in their favor, not yours.
Multi year terms lock in pricing and are worth considering if your core count and tier are stable. A three year commit at today's pricing protects you against Broadcom's future pricing adjustments. Given the trajectory of increases since the acquisition, multi year pricing is a hedge worth evaluating. The trade off is flexibility: if you reduce your environment significantly during the term, you've over committed.
7. Right Sizing Before Renewal
The core count you present at renewal is the core count you pay for. Running the Broadcom PowerCLI licensing script well before renewal gives you time to do something about what you find. The actions that reduce core count before the anniversary date:
- Remove hosts from vCenter inventory that are dormant, decommissioned, or not actively running workloads. They don't need to be licensed if they're not in use.
- Consolidate underused clusters. Merge lightly loaded clusters where the workloads are compatible and the combined utilization fits on fewer hosts.
- Right size HA admission control. Calculate the minimum host count for your actual workload capacity plus your chosen HA tolerance. Every host above that minimum is a licensing cost with diminishing operational return.
- Evaluate whether any clusters can run at a lower tier. Standard instead of VVF, VVF instead of VCF. Run the feature audit first to confirm what's actually in use.
- For environments with a mix of core counts, verify the 16-core minimum applies per CPU, not per host. A two socket server with two 8-core CPUs has 16 actual cores but 32 licensed cores. Replacing it with a single socket 32-core server cuts licensed cores in half for the same compute.
8. When the Bill Makes Alternatives Worth Evaluating
The migration conversation isn't hypothetical anymore. Customers reporting 8x to 15x cost increases have real alternatives that didn't exist or weren't mature enough to seriously consider five years ago. This isn't an endorsement of any specific alternative. It's an honest framework for when that conversation is worth having.
The VMware bill justifies a migration evaluation when the three year subscription cost exceeds the cost of migration plus three years of alternative platform licensing plus the operational investment to retrain. For many mid market environments, that math is now in favor of evaluating Proxmox VE, Nutanix AHV, or Azure Local. The migration isn't free and it isn't fast, but neither is a contract that tripled your infrastructure spend with no change in value delivered.
The environments where staying on VMware is the clearest answer are those that use VCF's full stack: NSX for microsegmentation, Tanzu for Kubernetes workloads, Aria for automation. If those features are embedded in your operations, the migration cost and operational disruption of replacing them is genuinely high. If you're running VMs on vSphere and nothing else from the bundle, the calculus is different.
The question worth asking is: what are you actually using from what you're paying for? If the answer is "mostly just vSphere and vCenter," that's worth writing down and presenting to whoever approves the renewal budget.
Key Takeaways
- Every physical core counts. The 16-core minimum per CPU means you're likely paying for more cores than your hardware actually has. The 72-core minimum order attempted in April 2025 was reversed after backlash, but expect Broadcom to try again. Run the official Broadcom PowerCLI counting script before any renewal to know your exact number.
- Fewer sockets with more cores per CPU is the right hardware direction for minimizing licensing cost. Two socket servers with 16-plus cores per CPU avoid the 16-core floor penalty entirely. Four socket servers with low core CPUs pay a significant licensing premium for the same compute.
- Audit your feature usage before renewal. If you're on VVF but not using DRS, VDS, or vSAN, you're a Standard candidate. If you're on VCF but not using NSX or Tanzu, you're a VVF candidate. That feature audit is your evidence for the downgrade conversation.
- The 20 percent late renewal penalty applies retroactively from the anniversary date. Start renewal discussions at least six months out. The negotiating position is significantly worse under deadline pressure.
- Not every cluster needs to run the same tier. Production clusters running DRS and VDS need VVF minimum. Dev and test clusters that don't use those features can run Standard. License each cluster at the tier it actually requires.
- Broadcom's compliance posture is materially more aggressive than VMware's was. Telemetry is on by default. Audit clauses are tighter. Mixing perpetual and subscription licenses can trigger reviews. Get legal clarity on any remaining perpetual licenses before the next renewal negotiation.
- If your three year VMware cost exceeds migration cost plus three years on an alternative platform, the migration conversation is worth having. Mid market environments not using NSX or Tanzu have the clearest case for evaluating alternatives.