VMware Core Count Compliance Under Broadcom: How to Calculate Your Licensing Correctly

The Core Count Problem: Why Most Enterprises Are Under-Licensed

When Broadcom acquired VMware in 2023 and transitioned to subscription-only licensing in 2024, most enterprises did not immediately recalculate their core count requirements. Many organisations deployed on the old perpetual licence assumption, counting logic cores or sockets rather than physical cores. Now, when renewals arrive, the licensing gap becomes visible: they are significantly under-licensed under Broadcom's new metric, and back-billing calculations can exceed millions of dollars.

The core count calculation is deceptively simple in principle but frequently misexecuted in practice. The challenge is not the arithmetic—it is identifying which hosts to count, understanding the 16-core CPU floor, and recognising that Broadcom already has telemetry visibility into your actual usage through CSSM (Compliance and Security Monitoring Service) phone home data.

Broadcom's telemetry gives them near-real-time visibility into your actual core count. Non-compliance discovered during renewal audit is often backed by months of vCenter data already in Broadcom's possession.

How Broadcom Counts Cores (The Official Rules)

Broadcom's core count licensing for VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF) follows these rules:

• Count physical cores only. Not logical cores (hyperthreading), not sockets, not virtual machines. Physical cores across all ESXi hosts managed by a single instance of vCenter Server.
• 16-core minimum per CPU. If a server has a CPU with fewer than 16 physical cores, you still license 16 cores for that CPU. This means a dual-socket server with two 8-core CPUs is licensed as 32 cores minimum (16 per CPU), not 16 total.
• Round up to the nearest core pack. Core packs are typically sold in 32-core increments. If your total is 73 cores, you buy a 96-core entitlement.
• Per-product requirement. The 72-core minimum applies to each product independently. You cannot combine core counts across VCF Standard, VCF Advanced, and VCF Premier to meet the 72-core threshold. Each product must meet 72 cores at purchase.
• vSAN licensing is separate. vSAN is licensed per TiB (tebibyte) of raw storage capacity, not per core. Calculate vSAN and core licensing independently.

The 72-Core Minimum: What It Means in Practice

On April 10, 2025, Broadcom enforced a new policy: you cannot purchase a VCF or VVF subscription below 72 cores per product. This is not a per-host minimum or a per-CPU requirement. It is a per-purchase minimum. If you have a single ESXi host with 16 cores, you still must purchase a 72-core (or higher, in 32-core increments) licence for the product you choose.

For large organisations with 500+ cores, this is immaterial. For mid-market enterprises with 40-60 cores deployed, it forces the purchase of entitlements for capacity they do not yet use. For start-ups or test clusters, it creates a high barrier to entry on Broadcom VMware.

The 72-core minimum also blocks one common workaround: splitting deployments across multiple vCenter instances to reduce licensing scope. If you had two 50-core clusters on separate vCenter servers, you previously licensed 50 cores per cluster. Under the new rule, you license 72 cores per product per vCenter instance (100 cores per vCenter after rounding). This increases effective cost for fragmented deployments.

Step-by-Step: How to Calculate Your Licence Requirement

Follow this process to establish your true core count compliance baseline:

Step 1: Export ESXi Host Inventory

Log into vCenter Server. Navigate to Hosts and Clusters. Export the full host list including make, model, and CPU specification. For each host, identify the physical CPU count and cores per CPU from the system documentation or CPU specification sheet. Do not rely on vCenter's "logical processor count" field—this includes hyperthreading.

Step 2: Calculate Per-Host Core Requirement

For each ESXi host, multiply CPU count by cores per CPU. If a server has two 24-core Xeon processors, the core count is 2 × 24 = 48 cores. Apply the 16-core floor: if the result is below 16 for any single CPU, round that CPU up to 16. A dual-socket server with two 8-core CPUs is calculated as 16 + 16 = 32 cores, not 16.

Step 3: Sum Across All Hosts in Scope

Add up the per-host core requirements for all ESXi hosts managed by the vCenter instance you are licensing. This is your base licence requirement. If the total is less than 72 cores, round up to 72 (for single product). If above 72, round up to the nearest 32-core increment.

The 16-core CPU floor is frequently overlooked. Organisations with many older, lower-core servers often discover their actual core requirement is 40-60% higher than the simple sum of physical cores.

Step 4: Identify Non-Licensed Hosts

Verify your licence entitlements against the host inventory. If you have ESXi hosts connected to vCenter but no corresponding licence purchased, you are out of compliance immediately. This includes test hosts, DR failover hosts, and hosts in standby capacity that are powered on and managed by vCenter.

Step 5: Validate Against Previous Deployments

If you have legacy perpetual ESXi licences (vSphere Standard, Enterprise), map them to the current host inventory. Broadcom does not automatically convert perpetual to subscription. The absence of an active subscription for licensed hosts is a compliance violation, even if you held perpetual licences previously.

The PowerCLI Compliance Audit Tool

Broadcom and community contributors have developed PowerCLI-based scripts to automate core count calculation. The Broadcom VMware licencing PowerCLI module queries vCenter for all connected ESXi hosts, pulls physical CPU and core specifications, applies the 16-core floor, and generates a compliance report.

To use PowerCLI for core count audit:

1. Install PowerCLI 13.0 or later and the Broadcom VMware.Compliance module.
2. Connect to vCenter: Connect-VIServer -Server vcenter.example.com
3. Run the core count report: Get-VMHostCoreCount -Full
4. Export results to CSV for licence mapping and audit preparation.

The PowerCLI output provides per-host core counts, total core requirement, and flags any hosts without matching licence entitlements. Many organisations run this script quarterly to track growth and catch compliance gaps before renewal audits.

Common Calculation Errors and Their Consequences

Real-world core count audits reveal these recurring errors:

Error 1: Counting Logical Cores

A server with two 12-core Xeons with hyperthreading has 48 logical processors but only 24 physical cores. Many organisations mistakenly enter 48 into their core count, overshooting their actual licence requirement by 100%. When Broadcom cross-checks against vCenter telemetry, the discrepancy is flagged.

Error 2: Ignoring the 16-Core Floor

A test cluster with three 8-core hosts is calculated as 3 × 8 = 24 cores. Under Broadcom's rule, each host requires 16-core minimum, so the actual requirement is 16 × 3 = 48 cores. The 100% difference triggers immediate non-compliance remediation.

Error 3: Missing Hosts in Scope

When organisations consolidate or decommission hosts, they sometimes forget to remove them from vCenter. A powered-off host still connected to vCenter still counts toward core licensing if it is managed by the vCenter instance you are licensing. Broadcom's audit sees the host in CSSM telemetry and flags it as unlicensed.

Error 4: Misclassifying Host Tier

A Standard-licensed host running Enterprise features (e.g., vSAN, DRS across clusters, Storage vMotion) is out of compliance. The feature use is visible in vCenter logs and CSSM telemetry. Simply upgrading the host to Enterprise retroactively creates back-billing liability.

Six Steps to Maintain Ongoing Core Count Compliance

1. Run Quarterly PowerCLI Audits

Schedule a quarterly core count report from vCenter. Compare the output to your current licence entitlements. Flag any hosts added, removed, or modified. This early warning system catches compliance drift before Broadcom's renewal audit.

2. Document CPU Specifications

Maintain a spreadsheet of all ESXi hosts with make, model, CPU type, core count per CPU, and socket count. This documentation is your defence if Broadcom disputes your core calculation during audit. Attach CPU specification sheets from the manufacturer.

3. Track Licence Expiry Dates

Set calendar reminders 90 days before VMware subscription renewal dates. A lapsed subscription is non-compliance, triggering the 20% late-renewal penalty when you renew. Do not allow subscriptions to lapse, even for short periods.

4. Prepare for CSSM Audit

Broadcom's CSSM telemetry gives them a continuous data feed from your vCenter environment. Before renewal, proactively run a vCenter compliance report and reconcile it against your licence entitlements. If you find discrepancies, disclose them to Broadcom ahead of the formal audit and propose a settlement.

5. Build Negotiation Leverage

If you discover under-licensing before Broadcom's audit, you have leverage to negotiate the settlement. Engage a Broadcom VMware negotiation specialist to structure the back-billing settlement alongside your renewal. Most settlements include price caps and true-up provisions that protect you from similar situations in the future.

6. Plan for Alternatives

If Broadcom VMware core count compliance costs are escalating faster than your infrastructure budget, evaluate VMware alternatives including Proxmox, OpenStack, and Nutanix. The decision point is whether the cost of staying on VMware exceeds the cost of migration. A documented migration evaluation creates negotiation leverage for better renewal pricing.

Proactive disclosure of compliance gaps to Broadcom before audit yields faster settlement and often includes relief from late-renewal penalties. Reactive discovery during audit is treated as non-compliance and penalties are applied.