Broadcom's restructuring of vSphere licensing from per-processor to per-core is one of the most significant commercial changes in enterprise infrastructure software in a decade. This guide explains precisely what changed, how to calculate your new cost exposure, and what organisations can do to minimise the impact.
Under VMware's pre-acquisition licensing model, vSphere was licenced on a per-physical-socket basis with a cap: two sockets per standard licence, with no limit on the number of physical cores per socket. This model was established when processors typically had 4–8 cores, and remained in place as processor core counts grew — meaning that customers who refreshed their server infrastructure to modern high-density processors (with 32, 64, or even 128 cores per socket) paid the same amount as customers running the same number of sockets with far fewer cores.
Broadcom has eliminated this model entirely. Under the new structure announced effective February 2024, all vSphere licensing is per physical core, with a minimum of 16 cores per CPU. There are no per-socket licences, no caps on core counts within a socket, and no legacy pricing structures for existing customers beyond the perpetual licence transition period. Every physical core on every in-scope host must be licenced, regardless of the number of VMs running on that host or the utilisation of those cores.
A customer running two-socket servers with 32-core processors previously paid 1 licence (covering 2 sockets). Under the new per-core model, they pay for 64 cores — typically 4x the previous licence cost for the same hardware, even before accounting for the subscription premium versus perpetual pricing.
| Dimension | Old VMware Model (pre-2024) | New Broadcom Model (2024+) |
|---|---|---|
| Licence unit | Per physical socket (2 sockets/licence) | Per physical core |
| Core density impact | None — unlimited cores per socket | Full cost per core, minimum 16/CPU |
| Licence type | Perpetual + annual SnS | Annual subscription only |
| Minimum purchase | 1 licence (2 sockets) | 16 cores per CPU minimum |
| vSphere Standard | ~£700–900 per socket licence | ~£45–80 per core per year (VVF/VCF) |
| vSphere Enterprise Plus | ~£2,800–3,500 per socket licence | Included in VCF or VVF subscriptions |
| Product structure | Standalone vSphere editions | VCF (all features) or VVF (compute only) |
The per-core counting rules under Broadcom's new model are straightforward but have several nuances that affect the total licence count for any given environment:
All physical cores are counted. You cannot exclude unused, disabled, or low-utilisation cores from the licence count. Whether a core is running VMs or sitting idle, it is in scope if the host is running vSphere or is managed by vCenter.
Minimum 16 cores per processor. If your servers have processors with fewer than 16 physical cores — common in older infrastructure still in production — you must still licence a minimum of 16 cores per CPU. This means organisations with legacy dual-socket servers containing, say, 8-core processors must pay for 32 cores (16 per CPU × 2 CPUs) when the actual core count is 16.
Hyper-threading does not affect licence count. Physical cores are what count, not logical processors. A 32-core processor running hyper-threading to present 64 logical CPUs is licenced as 32 physical cores.
vCenter scope determines the licensing boundary. Any host managed by a vCenter Server instance is in scope for licensing. Hosts that are truly standalone (not managed by vCenter) are not required to be licenced under the subscription model — but this creates operational management limitations that make truly standalone operation impractical at enterprise scale.
The actual cost impact of the per-core transition varies dramatically based on the server infrastructure mix. Organisations that have refreshed to modern high-density processors (AMD EPYC or Intel Xeon Scalable with 32–64 cores per socket) face the largest relative cost increases. Organisations running older hardware with moderate core counts may see smaller relative increases but still face the fundamental shift from perpetual to subscription economics.
| Server Profile | Cores per Host | Annual Old Cost (est.) | Annual New Cost (VCF) | Cost Change |
|---|---|---|---|---|
| Legacy 2S / 8-core (16 min applies) | 32 cores (16 min) | ~£600 SnS | ~£3,200 | +433% |
| Standard 2S / 16-core | 32 cores | ~£600 SnS | ~£3,200 | +433% |
| Mid-density 2S / 32-core | 64 cores | ~£600 SnS | ~£6,400 | +967% |
| High-density 2S / 64-core (EPYC) | 128 cores | ~£600 SnS | ~£12,800 | +2,033% |
| 4-socket server / 32-core | 128 cores | ~£1,200 SnS | ~£12,800 | +967% |
VCF pricing at indicative £100/core/year. Old SnS at indicative £300/socket/year for Enterprise Plus. Actual pricing varies by negotiation. See our VMware subscription pricing guide for detailed modelling.
Organisations that have recently invested in AMD EPYC or Intel 4th/5th-gen Xeon servers specifically for consolidation efficiency are the hardest hit by the per-core model. A 16-node cluster of AMD EPYC 9654 servers (96 cores/socket, 2 sockets) carries 3,072 licensable cores — representing annual VCF subscription costs of £300,000+ for a single cluster. This is frequently more than the organisation paid for VMware licences for its entire estate under the old model.
Broadcom offers two subscription tiers for vSphere environments, and choosing between them correctly can significantly reduce costs:
VMware vSphere Foundation (VVF) provides the core compute virtualisation stack — vSphere hypervisor, vCenter management, and basic Tanzu Kubernetes integration. It does not include vSAN (software-defined storage) or NSX (software-defined networking). VVF is priced at approximately 40–60% of the VCF per-core price.
VMware Cloud Foundation (VCF) is the full-featured stack: vSphere, vSAN, NSX, and Aria management tools, all bundled at a higher per-core price. Broadcom's default commercial position is to price all customer environments as VCF-eligible, but this is negotiable for environments that do not require vSAN or NSX.
The most common over-licensing scenario under Broadcom's commercial approach is applying VCF pricing to environments where VVF is architecturally sufficient. If your organisation uses external SAN or NAS storage rather than vSAN, you have a strong technical argument that VVF is the appropriate product. Similarly, if you use a third-party network virtualisation platform or do not deploy NSX, VCF's bundled NSX is delivering no value. Securing VVF pricing for these environments can reduce per-core costs by £40–60 per core per year at commercial list. For a 500-core environment, this represents £20,000–30,000 per year in savings. For the full VCF bundle analysis, see our VCF licensing guide.
Perpetual vSphere licences purchased before the acquisition transition date remain technically valid — the software licence itself does not expire. However, Broadcom has made the support position for perpetual licences increasingly untenable:
The practical implication is that perpetual licences can continue to run the software already deployed but cannot be safely extended indefinitely as a production platform without some form of support coverage. Third-party support from organisations like Rimini Street exists for some VMware products and may extend the viable life of perpetual licences. For organisations with modern, stable VMware environments and strong internal expertise, a structured 12–24 month perpetual holdover period — combined with parallel migration planning — can defer Broadcom subscription spend while the migration strategy matures. However, this carries security risk that must be explicitly assessed and accepted by appropriate stakeholders.
Facing an unexpected vSphere per-core cost increase?
The per-core transition has created a specific and significant commercial problem for organisations that invested in server consolidation using modern high-density processors. AMD EPYC processors with 96 or 128 cores per socket, and Intel Xeon Scalable processors with 60+ cores, were purchased specifically to reduce server count and power consumption. Under the old per-socket model, this consolidation reduced VMware costs (fewer sockets). Under the new per-core model, the consolidation strategy is inverted: more cores per server means higher licensing cost per server, potentially eliminating the economic benefit of consolidation.
This creates a genuine hardware strategy conflict. Organisations planning server refresh cycles need to model the licensing implications of core density decisions before committing to hardware configurations. In some cases, running more lower-density servers is cheaper on a total cost basis under the per-core model than running fewer high-density servers — the opposite of the previous optimisation. This analysis needs to be incorporated into infrastructure planning before hardware purchases are committed.
For organisations that have already invested in high-density server infrastructure, the most effective mitigation strategies are: aggressive VVF qualification (where applicable), workload migration to reduce the number of VCF-licenced hosts, and using the hardware investment as a migration leverage point — demonstrating to Broadcom that the per-core cost on your modern infrastructure is disproportionate and creates a compelling migration case that Broadcom would do better to accommodate with competitive per-core pricing.
The per-core transition creates specific negotiation angles that did not exist under the old per-socket model. Experienced advisors use these angles to achieve per-core price reductions and modified terms that partially offset the cost impact of the transition:
Technical challenge on in-scope core count. Any host where there is ambiguity about whether it should be in the VCF subscription scope is a negotiation opportunity. Hosts used exclusively for non-virtualised workloads, hosts in isolated test networks, and hosts pending decommission can all be challenged. Reducing the baseline core count by 10–15% through scope challenge has the same economic effect as reducing the per-core price by the same percentage.
Historic spend reference. The jump from perpetual SnS costs to per-core subscription costs is factually extreme for most customers. Presenting Broadcom's commercial team with a formal document showing the percentage increase from your previous VMware spend baseline to the proposed VCF subscription cost — particularly if the increase is 3x or more — provides a factual basis for requesting commercial accommodation. Broadcom's teams are authorised to offer additional discounts where the spend delta is disproportionate.
Hardware investment timeline. If you have recently purchased high-density servers, the timing of that investment can be used as a negotiation argument. Organisations that made hardware purchases specifically optimised for the old VMware model can credibly argue that Broadcom's retroactive model change has imposed unplanned costs and request a commercial accommodation for a defined transition period.
Our advisors provide independent per-core cost modelling and negotiation strategy for VMware environments of all sizes. Get the numbers before Broadcom presents theirs.