Cracking the Per‑Core VMware Licensing Model: Calculations and Cost Pitfalls
VMware’s move from per-processor to per-core licensing is catching many enterprises off guard.
Broadcom’s new per-core VMware pricing model, with a minimum of 16 cores per CPU and a recent 72-core purchase minimum, is dramatically reshaping renewal costs.
This article demystifies the changes, illustrates how costs can multiply (in some cases by 5×–40×), and offers practical guidance for VMware Foundation Suite customers to avoid common pitfalls when renewing under Broadcom.
From Processors to Cores: A Licensing Sea Change
Broadcom’s VMware licensing overhaul marks a decisive break from the past. VMware vSphere licensing has transitioned from a per-CPU (socket) model to a per-core model.
Under the old model, one processor license covered a CPU (often up to a core limit, historically 32 cores per CPU).
Now every physical core must be licensed individually. This shift aligns with industry trends toward subscription and usage-based models, but it can catch customers off guard who are accustomed to simpler CPU-based counts.
Real-world scenario: An IT team with 10 dual-processor hosts (20 CPUs total) assumed they’d renew 20 licenses as before.
Instead, with eight cores per CPU, they now must license 160 cores even though nothing in their hardware changed. The cost implications served as a wake-up call, necessitating a swift revision of the budget.
Takeaway: Understand your core counts now. Map out how many physical cores power each VMware host.
The first step in cracking the per-core VMware licensing model is realizing you’re licensing at the core level, which means higher counts and potentially higher costs than the old per-processor math.
VMware Cloud Foundation vs vSphere Foundation: Licensing, Features, and Pricing Comparison
What Exactly Counts as a “Core”?
Not all “cores” are equal in the era of virtualization and cloud. VMware defines a “core” consistently as one physical computing unit, even if it’s abstracted:
- On physical servers, a core is a physical processor core. Hyperthreading doesn’t double your core count – two hardware threads (two vCPUs) on one physical core still count as one core.
- In virtualized environments, a core refers to the underlying physical core that may present as one or more virtual CPUs to your VMs. Essentially, the license count is tied back to the physical cores powering your hypervisor cluster, not the number of virtual CPUs assigned.
- In public cloud deployments: if you’re leveraging VMware Cloud or a similar service, a core is again a single physical processor core on the host (even if cloud providers label them as “vCPUs” or “Virtual CPUs”). For example, an Azure VM with eight vCPUs typically corresponds to four physical cores with hyperthreading – VMware would count those four cores toward your license usage.
Real-world scenario: A procurement manager assumed their cloud VMs’ “8 vCPU” meant 8 cores of licensing. In fact, due to hyperthreading, those instances ran on four physical cores. Misinterpreting this would have meant over-purchasing licenses. Clarifying the core definition saved the team from licensing overkill.
Takeaway: Precisely identify what constitutes a core in your environment. Count the physical cores in hosts (and remember that two vCPUs equal 1 core, considering hyperthreading). This ensures you neither under-count (risking compliance issues) nor over-count (wasting budget) when applying VMware’s per-core licensing.
The 16-Core Minimum (Per CPU) – And the New 72-Core Threshold
Under Broadcom’s rules, VMware licenses carry two critical minimums:
- 16 cores per CPU: Even if a processor has fewer cores, VMware treats it as if it has 16 cores. For example, a server with a single 8-core CPU is licensed as 16 cores. This per-processor floor means small or underutilized chips get no cost break – a key pitfall for environments with older or low-core-count hardware.
- 72 cores per product minimum: As of April 10, 2025, any VMware product license purchase (for example, vSphere Foundation Suite) requires a minimum of 72 cores’ worth of licenses. This is a purchase threshold, not per-CPU – meaning your overall order for a given product must cover 72 cores or more, even if your actual usage is less.
Real-world scenario: A regional office runs a 64-core server (two 32-core CPUs). Under the 16-core-per-CPU rule, those two CPUs would count as their full 64 cores (each already above 16).
However, with the new 72-core minimum, even this single-server setup is no longer sufficient – the company must purchase licenses for 72 cores.
Meanwhile, a remote site with one 12-core server (below 16 cores per CPU) is affected twice: VMware rounds each 12-core CPU up to 16, then rounds the entire environment up to 72. A small 12-core deployment effectively pays for 72 cores of capacity.
Takeaway: Always budget for VMware’s minimums. If you have a small deployment, anticipate paying for far more cores than you physically have.
The 16-core-per-CPU rule and 72-core minimum order size mean that even modest environments are priced similarly to those of much larger scale.
Plan hardware purchases and consolidation accordingly; it may make sense to run fewer, larger hosts rather than many tiny ones, as you’ll pay a 72-core baseline regardless.
How Costs Can Multiply – Sticker Shock in Action
Moving to per-core licensing has led to reports of 5× to 40× cost increases in support and subscription fees for some VMware customers.
Why such a dramatic range?
Several factors compound the costs:
- Core-count explosion: Many customers simply didn’t factor in the number of cores they were running. If you previously licensed 4 CPU sockets, each with 16 cores, you had four licenses; now you need 64-core licenses. In one case, a mid-sized firm with ~64 total cores saw its VMware renewal quote increase roughly fivefold compared to its previous per-CPU support costs. The more core-dense your servers, the bigger the jump – environments with newer 28, 32, or 64-core processors per socket face huge uplifts versus the old model.
- Mandatory bundling: The VMware Foundation Suite (vSphere Foundation) includes vSAN, advanced automation (Aria/Operations), and more, all rolled into one. While feature-rich, it means you’re paying for a broader bundle. Some organizations that previously bought “just vSphere” (and perhaps skipped vSAN or other add-ons) now must subscribe to the full suite. If you weren’t using those extras before, the bundle feels costly. For example, an educational institution that only needed basic virtualization was quoted for the entire Cloud Foundation stack (including NSX and more) with no academic discount—a worst-case scenario that resulted in costs spiking over ten times.
- No more perpetual licenses: Under Broadcom, even customers with existing perpetual licenses and support contracts will eventually be required to transition to subscriptions. What was once a one-time license fee plus annual support is now an ongoing subscription. Many are finding that the new annual subscription for a given setup can be as much as their previous one-time license cost – effectively multiplying expense over a multi-year period. One public sector client reported a jump from ~$100K in yearly support to nearly $500K per year under a subscription package covering the same environment.
Practical example: Imagine a small enterprise that paid ~$20,000 annually for support on their vSphere Enterprise Plus and vSAN perpetual licenses. Upon renewal, they’re told those SKUs are retired – instead, they need a VMware Foundation Suite subscription for all 100 cores in use.
The quote comes back at $100,000 per year. That’s a 5× increase for essentially the same functionality, now delivered as a bundle.
Suppose that the company also has a few branch servers that individually fall under the 72-core minimum. In that case, the effective cost per branch increases even higher – sometimes approaching 20–30 times what a slim perpetual license used to cost for that small deployment.
Takeaway: Expect sticker shock and model out different scenarios. Don’t assume your renewal will resemble past quotes. Calculate costs for your core counts and product tiers, then assess whether all included components are necessary.
In some cases, rightsizing (or even downsizing) your VMware footprint or exploring alternative hypervisors can become a sensible option when faced with a budget increase of 5–10 times. The goal isn’t fear, but preparedness: know the potential cost and have a plan.
The Price of Procrastination: 20% Late Renewal Fee
A new costly trap in VMware contracts is the late renewal penalty. Broadcom now imposes a 20% fee on the first year of a subscription renewal if you miss your anniversary date.
In plain terms, if your VMware Foundation Suite subscription expired last month and you renew today, you’ll pay a one-time 20% premium on top of your normal renewal cost.
This is substantially steeper than typical grace penalties in the industry (for example, Microsoft’s is around 3%). It’s Broadcom’s way of enforcing on-time commitments – essentially a financial stick to ensure renewals don’t slip.
Real-world scenario: A procurement department, used to some flexibility on support renewals, let a VMware contract lapse while awaiting final budget approval.
When they attempted to reinstate it a couple of weeks later, the quote included an unexpected $30,000 “penalty” line item – approximately 20% of their annual spend – simply because the renewal had not been processed before expiration. With no wiggle room, they had to eat the cost.
Beyond fees, an expired subscription puts customers in a weak negotiating position.
If you lapse, Broadcom may treat you as a new sale rather than a renewal, which could result in the forfeiture of any loyalty discounts. Some customers even consider starting fresh subscriptions (to avoid the penalty) – but that might involve additional back-dated costs or loss of certain transition credits.
Takeaway: Mark your calendar and renew on time.
Treat VMware renewal dates as immovable deadlines – start the process early. Engage your Broadcom/VMware representative at least 90 days in advance to obtain quotes and approvals.
The 20% late fee is a pure waste of spending. By staying proactive, you not only avoid penalties but also retain more leverage to negotiate favorable terms (since Broadcom knows you have the option to let it lapse and switch platforms – leverage you lose after expiration).
Long-Term Contracts: Pressure to Commit 3–5 Years
Another tactic employed by Broadcom’s VMware pricing strategy is pushing customers toward longer-term commitments.
Enterprises are finding strong encouragement – sometimes overt, sometimes via pricing incentives – to sign three-year or five-year subscription agreements instead of just annual terms.
Why? Broadcom secures revenue and the customer is locked in, while you may gain some price predictability.
However, longer terms carry their considerations:
- Discounts vs. flexibility: You may receive a better per-core rate or a larger bundle if you commit to three or more years upfront. Some customers report initial trade-in offers that included 50% off list price – but often these deals require multi-year commitments. The trade-off is reduced flexibility; if your strategy or budget changes in year 2, you’re already locked in (or face penalties to break).
- Budget predictability: A 3-year contract can shield you from year-over-year price hikes (and given recent changes, many expect further increases). It also simplifies budgeting – you know the VMware cost line item for the next few years.
- Risk of shelfware: Committing to long-term investments often means forecasting your core needs and potentially “pre-paying” for future growth. Be cautious of overcommitting core counts or add-on services that you may not fully utilize. For instance, locking in 500 cores for 5 years, only to virtualize less than that, leaves money on the table. Broadcom isn’t likely to voluntarily scale your contract down later.
Real-world scenario:
A global manufacturer negotiating their VMware Enterprise License Agreement found that a 1-year renewal quote was sky-high – but the sales team dangled a multi-year deal at a lower annual rate.
The catch: it bundled in Cloud Foundation licenses (for future use) and required a 5-year term. The company had to weigh taking a shorter-term financial hit versus betting on VMware as a platform for the next five years.
In the end, they chose a 3-year middle ground, ensuring they got a predictable price while not stretching too far out in a fast-changing tech landscape.
Takeaway: Align contract length with your strategic roadmap.
If you’re confident VMware will remain a cornerstone for the next 3–5 years, a longer deal can secure better pricing (and guard against known increases like the 72-core rule).
Negotiate for flexibility where possible, such as options to expand at a set rate or clauses for adjustments if your business scales down. And involve finance early – multi-year deals need careful approval and cash-flow planning, but can pay off if done prudently.
Navigating Common Licensing Pitfalls
The new licensing model introduces several pitfalls that can trap even seasoned IT and procurement teams.
Here’s a quick overview of major VMware licensing pitfalls vs. mitigation strategies:
| Pitfall | Impact | Mitigation Strategy |
|---|---|---|
| Under-counting cores (e.g. treating vCPUs as cores) | Non-compliance, surprise true-up costs in an audit. | Do a core audit: Inventory all physical cores in hosts. Use VMware’s definition (count hyperthreaded pairs as one). Double-check any BYO cloud deployments. |
| Small deployment, big minimum (72-core rule) | Over-spending on unused capacity for each product. | Consolidate or consider alternatives: If you have many tiny vSphere installs (ROBO sites, labs), consider merging them onto fewer hosts or evaluate lighter hypervisors for those cases to avoid paying 72 cores each. |
| Hardware with low-core CPUs (below 16) | Paying for cores you don’t have on each CPU. | Retire or repurpose low-core-count servers: It might be more cost-efficient to use fewer modern CPUs with higher cores. You’ll pay for 16 regardless, so 4-core and 8-core CPUs give poor license ROI. |
| Late renewals (missing anniversary) | 20% cost penalty and lost leverage. | Track and act early: Set renewal reminders well in advance. Engage vendors 3-6 months out to ensure timely processing. |
| Multi-year lock-in without exit | Potential overpayment if strategy changes or downsizing occurs. | Negotiate safeguards: Include volume flexibility in contracts if possible (e.g. ability to reduce cores under certain conditions), or opt for a slightly shorter term if uncertain. Also, regularly review utilization so you can adjust at next renewal. |
Recommendations
To make the best of a tough licensing landscape, consider these expert tips:
- 1. Baseline your environment: Conduct a full audit of your current VMware deployment – count physical cores, note which products (Foundation Suite, vSAN add-ons, etc.) you’re using, and what features you need. Solid data is your best tool in negotiations.
- 2. Right-size your hardware: Evaluate if your server strategy is optimal under per-core licensing. Sometimes using fewer servers with more cores can lower licensing costs compared to many underutilized servers (due to that 72-core floor). Conversely, extremely core-dense CPUs might incur huge costs – find a balance that minimizes license waste.
- 3. Consider alternate licensing or platforms for edge cases: For very small offices or DR sites running just a few VMs, assess if VMware is still cost-effective. Alternatives like Hyper-V or Proxmox, or cloud-hosted VMs, might meet those needs without a 72-core price tag. Keep VMware where it delivers value, but you don’t have to use it everywhere.
- 4. Engage VMware/Broadcom early and often: Don’t wait until a week before expiration to discuss renewals or issues. Broadcom’s processes can be rigid – early engagement gives you time to escalate, seek approvals, or find creative solutions (such as splitting an order to meet minimums).
- 5. Leverage enterprise agreements and bundles wisely: If you’re a large enterprise, look at VMware Cloud Foundation or other bundles; ironically, the per-core cost can be lower for the full bundle. Make it a point in negotiations – if you’re paying for a suite, ensure you get value (maybe training or deployment help for NSX, Aria, etc., that come with it).
- 6. Lock in pricing (if it makes sense): Given the pace of change, securing today’s pricing for 3–5 years might be smart if you plan to stick with VMware. Just be sure to benchmark that “discounted” multi-year deal against year-by-year costs and consider your confidence in VMware’s roadmap.
- 7. Watch for audit triggers: Broadcom is expected to be vigilant about compliance. Keep documentation of your core counts and license purchases. Avoid common triggers, such as deploying extra hosts without licensing them or repurposing a license outside the agreed-upon terms. Proactive compliance reviews can save you from an audit penalty (or at least prepare you for one).
- 8. Educate stakeholders: Ensure your IT architects, finance team, and procurement officers all understand the new model. Surprises often happen when one team assumes “we’re all set” on licensing. A short internal workshop or memo on “per-core licensing 101” can align everyone and avoid costly mistakes.
- 9. Explore support alternatives: If the subscription costs are untenable and you have perpetual licenses in use, one bridge option some enterprises take is third-party support for a year or two (to buy time). This is not a long-term strategy for everyone, but it can ease budget strain while you evaluate options – just weigh the risks of running without official VMware support.
- 10. Keep an eye on future changes: Broadcom’s VMware strategy is evolving. Pricing, bundles, and policies may adjust (for example, if there’s enough pushback, they could reintroduce a smaller edition or soften the terms). Stay informed through official announcements or advisory services, so you can adjust your strategy as needed.
Checklist: 5 Actions to Take
- Inventory your cores and licenses: Document how many cores you have per server, and what VMware subscriptions or entitlements cover them. This will highlight any shortfalls or over-provisioning under the new rules.
- Calculate renewal costs now: Don’t wait for the quote – use your core counts and current price per core to estimate what your next renewal will cost under the per-core model (remember the 72-core minimum!). Identify the gap between your current spend and your budget to avoid budget surprises.
- Schedule renewal milestones: Set a reminder at least 90 days before your VMware contract expiration. Kick off internal approval processes and vendor discussions early. Aim to have renewal paperwork ready well before the deadline to dodge the 20% late fee.
- Evaluate contract length options: Determine if a multi-year agreement is the best choice. If yes, determine your required core count and any growth for that period. Engage leadership for approval on a 3-year or 5-year commitment, and negotiate terms that protect your interests.
- Plan for the “what-ifs”: Create a contingency plan if VMware costs become unsustainable. This might include identifying pilot projects for alternative virtualization platforms or cloud migrations. While not an action to execute immediately, having a Plan B empowers you in negotiations with Broadcom and ensures you’re not cornered into a bad deal.
FAQ
Q: Why did VMware (Broadcom) switch from per-CPU to per-core licensing?
A: Broadcom moved VMware to per-core subscriptions to drive revenue and match modern consumption models. It ensures customers with higher-density CPUs pay more, and it converts one-time license sales into recurring subscription income.
Q: How does the 16-core and 72-core rule work in practice?
A: For each physical CPU in your servers, count at least 16 cores (even if the chip has fewer). Sum all those cores in your environment for a given VMware product – if the total is under 72, you still must purchase 72 cores’ worth of licenses. It’s essentially a minimum entry fee for any VMware product subscription.
Q: We have a small VMware deployment (under 72 cores). Are we stuck paying for 72?
A: Unfortunately, yes – under current policies, even a tiny deployment must meet the 72-core subscription minimum for each product. To mitigate this, you could consolidate workloads to use fewer, larger hosts (so at least you’re utilizing closer to what you pay for), or consider alternative solutions for those small environments.
Q: What happens if we let our VMware subscription expire?
A: If you let it expire, you lose support and rights to upgrade. Renewing late will incur a 20% penalty in addition to the subscription cost. In the worst case, if significantly lapsed, Broadcom might require back pay or treat it as a new purchase. It’s far better to renew on time or discuss options with Broadcom before expiration if you need an extension.
Q: How can we negotiate a better deal with Broadcom for VMware?
A: Come prepared with data and consider leveraging a larger commitment. For instance, a 3-year deal or a higher product tier (such as Cloud Foundation) might result in some discounts. Highlight your long-term loyalty and also be ready to discuss competitive alternatives – if Broadcom perceives a risk of losing your business, they may be more flexible. Engage your reseller or VMware account team and insist on clarity for any assumptions (like core counts or included features) in the quote.
Read about our Broadcom Advisory Services.
