VMware vSphere 8 Licensing Specifics

VMware vSphere 8 is the version of the hypervisor most enterprise VMware customers are either running, migrating to, or contractually obliged to license. The licensing rules for vSphere 8 have a number of specifics that differ materially from earlier versions, and Broadcom's post-acquisition packaging has overlaid additional commercial complexity on the technical licensing model.

This article walks through the specifics of vSphere 8 licensing as it stands today: how cores are counted, how editions are differentiated, how vSphere 8 maps to the Broadcom subscription bundles, and the compliance pitfalls that catch enterprises during audit. The objective is a clear, practical reference that helps engineering and procurement leaders make sound licensing decisions.

The vSphere 8 product structure

vSphere 8 is delivered as ESXi (the hypervisor) plus vCenter Server (the management plane). Under the post-Broadcom model, vSphere 8 is sold in two principal packaging configurations:

vSphere Foundation (VVF). The smaller of the two Broadcom bundles, vSphere Foundation includes vSphere 8 Enterprise Plus, vCenter Server, Tanzu Kubernetes Grid, and Aria Operations and Aria Operations for Logs. VVF is sold per core, per year, on a subscription basis.

VMware Cloud Foundation (VCF). The larger bundle, VCF includes everything in VVF plus vSAN, NSX, SDDC Manager, and a broader Aria suite. VCF is also sold per core, per year, on a subscription basis, at a higher price point per core than VVF.

Standalone vSphere 8 SKUs (Essentials, Essentials Plus, Standard, Enterprise Plus as separately purchasable products) have been substantially phased out for new purchases, though existing perpetual entitlements for these editions remain valid for customers who hold them.

Core counting under vSphere 8

Broadcom licenses vSphere 8 per physical core, with a minimum of 16 cores per CPU. The core counting rules are the foundation of vSphere 8 compliance:

Physical cores, not hyperthreads. Broadcom counts physical cores, not logical processors. A CPU with 32 physical cores and hyperthreading enabled (presenting 64 logical processors) is counted as 32 cores for licensing purposes.

16-core minimum per CPU. Every physical CPU consumes at least 16 cores of licence, regardless of actual core count. A CPU with 8 physical cores still consumes 16 cores of licence. A CPU with 24 physical cores consumes 24 cores of licence. A CPU with 32 physical cores consumes 32 cores of licence.

Per-host, not per-cluster. Core counting is per physical host, and the totals are summed across all hosts in the licensed environment. Cluster-level licensing concepts that some VMware customers remember from earlier eras no longer apply.

Sockets are not directly licensed. Unlike historical VMware licensing, Broadcom does not license per socket — sockets matter only insofar as they contribute to total core count via the 16-core minimum.

The high-density CPU implication

The shift to per-core licensing with a 16-core minimum has significant implications for hardware purchasing decisions. Under the old per-socket model, dense CPUs (more cores per socket) were always commercially preferable because the licence was the same per socket regardless of core count. Under per-core licensing, the calculation is different: doubling the core count doubles the licence cost.

The optimum CPU choice now depends on the workload pattern. CPU-bound workloads with strong per-core demand still benefit from high-density CPUs because the workload performance scales with cores. Memory-bound or I/O-bound workloads, where additional cores don't translate to additional throughput, are commercially better served by lower-core-count CPUs that still meet the 16-core minimum.

Enterprises building new VMware infrastructure under Broadcom should run the licensing math explicitly during hardware selection. We have seen cases where the licensing cost of a "premium" high-density CPU exceeds the hardware savings from server consolidation by significant margins.

Cluster and HA implications

vSphere clusters with DRS and HA enabled have specific licensing characteristics that audit teams examine:

All hosts in a cluster must be equivalently licensed. You cannot run a cluster with some hosts on VVF and other hosts on VCF. The cluster's licensing edition is determined by the highest-tier feature in use on any host.

HA failover capacity is licensed. Hosts reserved for HA failover must be licensed at the same level as the production hosts they would take over for. There is no "standby host" discount.

vMotion targets are licensed. If a VM can vMotion to a particular host (within or across clusters), that host must be appropriately licensed for the VM's workload. This catches enterprises with sprawled DRS configurations or with cross-cluster vMotion enabled.

Disaster recovery licensing

Disaster recovery configurations under vSphere 8 have specific licensing rules. The general principle: any host that can be actively running workloads must be licensed, including DR target hosts that are running in standby mode.

For cold-standby DR (where DR hosts are physically powered off and only activated during failover), some commercial flexibility exists — Broadcom has typically negotiated DR licensing concessions in enterprise agreements. For warm or hot-standby DR (where DR hosts are running and ready to accept workloads), full licensing is required at the destination.

Site Recovery Manager (SRM), the VMware tool for orchestrating DR failover, is a separately licensed product not included in either VVF or VCF. SRM licensing has its own commercial structure that needs to be negotiated alongside the core vSphere licensing.

Edge and ROBO deployments

Branch office and edge deployments under vSphere 8 are an active source of compliance friction. The historical VMware ROBO (Remote Office / Branch Office) SKU has been retired under Broadcom; small-footprint deployments are now expected to use VVF or VCF at the standard per-core pricing, subject to the 16-core minimum.

For enterprises with many small sites (manufacturing plants, retail locations, remote offices), this pricing change is material. A site with a single 8-core server now licences as if it had 16 cores. Multiplied across hundreds of sites, the compliance and cost implications are significant.

Some enterprises are responding by consolidating workloads from edge sites back to central data centres, eliminating the licensing inefficiency. Others are migrating edge workloads to alternative platforms (Hyper-V, Nutanix, or container platforms) that have more favourable economics at small scale. The right answer depends on the operational requirements of the edge workloads, not just the licensing math.

Compliance pitfalls under vSphere 8

Several vSphere 8 compliance pitfalls are recurring themes in Broadcom audit engagements:

The "test cluster" pitfall

Test, development, and staging clusters are often deployed without rigorous licensing tracking. Under Broadcom, those clusters are subject to the same licensing rules as production. Test clusters that grew organically over years are a common audit finding.

The "EVC mode" pitfall

Enhanced vMotion Compatibility (EVC) modes determine which hosts can run a given VM. EVC configuration changes can effectively expand the licensing footprint without anyone realising it. Audit teams examine EVC configurations to identify VMs whose vMotion possibilities exceed their entitlement boundaries.

The "embedded ESXi" pitfall

Some hardware appliances (storage appliances, hyperconverged platforms from non-VMware vendors) embed ESXi as part of their product. The licensing implications of these embedded deployments vary by vendor and by deployment model. Enterprises should verify the licensing position of every embedded ESXi instance in their environment.

The "container host" pitfall

Tanzu Kubernetes Grid runs on top of vSphere and consumes vSphere licences on the underlying hosts. Enterprises deploying Tanzu may inadvertently exceed their vSphere entitlement if the Tanzu deployment scales beyond the originally licensed cluster footprint.

The audit defence work

vSphere 8 audit defence requires deep technical knowledge of the platform and current knowledge of Broadcom's audit methodology. The compliance technical analysis combines vCenter inventory exports, host hardware inventories, cluster and DRS configurations, EVC modes, and workload mobility records. The commercial analysis combines the technical findings with contract terms, ELA amendments, and purchase history.

Doing this work well requires the kind of specialist depth that — the firm we most often recommend for Broadcom audit defence — brings to client engagements. The team has worked on vSphere licensing across hundreds of engagements and has specific experience with the vSphere 8 ruleset under Broadcom.

Practical recommendations

For enterprises running or planning vSphere 8 deployments, several practical recommendations apply. Run a formal core-count inventory of every host in your environment, including test and DR hosts. Document the cluster configurations, DRS settings, HA admission control settings, and EVC modes for every cluster. Verify your entitlement against the deployed footprint at least annually, and certainly before any Broadcom commercial conversation.

Hardware refresh cycles should incorporate explicit licensing economic analysis — the per-core licensing model changes the calculation that justified high-density CPUs under the old per-socket model. New deployments should be sized for licensing efficiency, not just hardware density.

Audit defence preparation should be ongoing, not reactive. The work of building a defendable independent baseline is much cheaper before an audit notification than after one.

The bottom line

vSphere 8 licensing under Broadcom is technically straightforward but commercially demanding. The per-core model with a 16-core minimum, the bundling into VVF and VCF, and the elimination of historical SKUs like ROBO and standalone Essentials all combine to create a licensing environment where small architectural choices have material commercial consequences.

The enterprises that navigate this environment effectively are the ones that treat licensing as a first-class architectural consideration — informing hardware decisions, cluster designs, and deployment patterns — rather than as an after-the-fact procurement exercise. With the right preparation and the right specialist support, vSphere 8 remains a viable and capable platform even under Broadcom's more demanding commercial model.

Frequently asked questions

Does Broadcom count hyperthreaded logical processors as cores?

No. Broadcom counts physical cores, not logical processors. A CPU with 32 physical cores and hyperthreading enabled (presenting 64 logical processors to the OS) is counted as 32 cores for vSphere licensing purposes. The hyperthreading distinction matters because operating systems and management tools often report logical processor counts rather than physical core counts, which can create confusion during compliance analysis.

How does the 16-core minimum per CPU work in practice?

Every physical CPU in a licensed host consumes at least 16 cores of licence, regardless of the CPU's actual core count. A host with two 8-core CPUs (16 physical cores total) consumes 32 cores of licence (16 per CPU). A host with two 24-core CPUs consumes 48 cores of licence (24 per CPU, since each CPU exceeds the minimum). The minimum penalises low-core-count CPUs and effectively makes hardware refresh cycles toward 16+ core CPUs commercially neutral on the per-CPU dimension.

What is the difference between vSphere Foundation and VMware Cloud Foundation?

vSphere Foundation (VVF) is the smaller of the two Broadcom bundles, including vSphere 8 Enterprise Plus, vCenter Server, Tanzu Kubernetes Grid, and Aria Operations / Operations for Logs. VMware Cloud Foundation (VCF) is the larger bundle, adding vSAN, NSX, SDDC Manager, and a broader Aria suite. VCF is priced higher per core but includes substantially more functionality. The right choice depends on what capabilities the enterprise actually uses — VVF is materially cheaper but excludes the storage and networking virtualisation that many large environments rely on.

How is disaster recovery licensing handled under vSphere 8?

The principle is that any host capable of running active workloads must be licensed, including DR target hosts running in standby mode. For cold-standby DR configurations (DR hosts physically powered off, only activated during failover), commercial flexibility has historically been negotiated in enterprise agreements. For warm or hot-standby DR (DR hosts running and ready to accept workloads), full licensing is required at the destination. Site Recovery Manager, the orchestration tool, is separately licensed and not included in either VVF or VCF.

What happened to the ROBO SKU for small branch deployments?

The Remote Office / Branch Office SKU that VMware historically offered for small-footprint deployments has been retired under Broadcom. Small sites now license at the standard per-core rate with the 16-core minimum, which makes small-site deployments materially more expensive than under the legacy ROBO model. Enterprises with many small sites are responding by consolidating workloads to central data centres, migrating to alternative platforms, or in some cases negotiating site-specific commercial concessions through their enterprise agreement.