Buy VMware/Broadcom licenses: complete per-core guide (VVF/VCF), vSAN included, editions, and how to choose

Executive summary — key changes and what they mean for your purchase

1. Subscription is the norm: today’s model revolves around subscriptions and bundles (VVF/VCF). Perpetual licenses are no longer the main path.
2. Per-core metric: you license physical cores (not threads) with a minimum of 16 per CPU. If a CPU has 12 cores, you still license 16.
3. Watch BIOS settings: physical cores are counted even if they are disabled in BIOS.
4. vSAN included per core: VVF includes 0.25 TiB/core and VCF includes 1 TiB/core as a licensing entitlement.
5. Standalone vSphere and vSphere 9: vSphere Standard/Enterprise Plus remain standalone through vSphere 8 (U3); vSphere 9 innovations arrive via VVF/VCF.
6. Compliance reporting: in 9+ there is compliance reporting (usage/licensing) you should control operationally.
7. Buying well = inventory + design: without a reliable inventory (hosts/CPU/cores) and a storage/performance direction, it’s easy to oversize—or come up short.
8. Practical rule: if you need advanced networking/security (NSX) and stack governance, look at VCF; if you want a strong on-prem virtualization bundle with vSAN included, look at VVF.

How licensing works: per-core metric and minimums (explained without the mess)

Most purchasing decisions become clear if you answer one question: how many physical cores do I actually have to license? Because, unlike other models, this is not about “how many VMs” or “how many sockets”: it starts from physical cores per CPU, with a minimum of 16 cores per CPU.

• Licensed per physical core, not threads (Hyper-Threading is not licensed).
• Minimum 16 cores per CPU: an 8-, 10- or 12-core CPU is licensed as 16.
• BIOS-disabled cores: they still count as physical cores for licensing.
• You license the hardware where the software runs (ESXi hosts / clusters).

Quick checklist to calculate cores (the one that actually works)

1. List your hosts in the cluster (or clusters).
2. For each host, capture CPUs and physical cores per CPU (not threads).
3. Apply the 16 cores/CPU minimum.
4. Multiply and sum to get the total cores to license.

Host; CPUs per host; Physical cores per CPU; vSAN? (yes/no); Notes
ESX-01; 2; 24; yes; Production
ESX-02; 2; 24; yes; Production
ESX-03; 2; 24; yes; Production

What licenses exist today—and what each one is for

If we simplify, there are two “main paths” for most organizations: VVF if you want a strong bundle for on-prem virtualization (with vSAN included), and VCF if you want a more complete platform (with NSX, lifecycle automation, and an SDDC focus). From there, you’ll find variants and add-ons.

If you want to go deeper on each bundle at MSAdvance: VVF guide · VCF guide · vSAN by TiB · vSphere Standard · vSphere Enterprise Plus.

VVF vs VCF vs vSphere 8: a realistic comparison (what usually decides the purchase)

A simple way to decide is to think “what problem are you solving”: virtualize well and simplify (VVF), or a full platform with advanced networking/security and stack governance (VCF). Standalone vSphere 8, meanwhile, usually appears when there are compatibility constraints or an ongoing transition.

Practical calculations: cores to license and included vSAN (with examples)

Base rule: you license the hosts’ physical cores (minimum 16 cores/CPU). With those licensed cores, you get an included vSAN entitlement: VVF = 0.25 TiB/core and VCF = 1 TiB/core.

If the included capacity is not enough, there are two common paths: (1) add vSAN by TiB, or (2) revisit whether the scenario (growth, FTT, performance) requires a redesign of the cluster.

How to size vSAN without surprises: included vs usable (what the customer actually feels)

This is one of the most common pitfalls: vSAN capacity included per core is a license entitlement, but the capacity you actually have for data depends on the design and your fault-tolerance policy.

1) Define what you need in “usable”, not in “raw”

“I need 40 TiB for data” is not the same as “I have 40 TiB of disks”. When you protect data (for example, to tolerate failures), usable capacity drops. That’s why, before buying, you should align:

• How much real data you need today and in 12–24 months.
• Whether you need failures to tolerate (FTT) and which policy.
• Whether your workload is sensitive to IOPS (VDI, databases) or is more “calm” (files, standard apps).

2) The key question: “Is the included entitlement enough, or do I need vSAN by TiB?”

In real projects, the decision usually comes down to one of these drivers:

• Data growth (you don’t want to be tight in 9–12 months).
• Protection (fault-tolerance policy reduces usable capacity).
• Performance (sometimes the design requires more disks/nodes, impacting total cost).

Typical purchase scenarios (and what usually fits best)

1) SMB with “classic” virtualization and moderate HCI

When it happens: 3–4 hosts, mixed workloads (ERP, file services, internal apps), small IT team.
Usually fits: VVF. It gives you a strong bundle and typically simplifies licensing and operations, with vSAN included per core.

2) Organization with serious networking/security requirements and standardization

When it happens: multiple clusters, environments owned by different teams, need micro-segmentation, more audit/control.
Usually fits: VCF if NSX and stack governance provide real value.

3) Edge/ROBO: two nodes, remote sites, factories, retail

When it happens: small footprint, little room for “tinkering”, stability is the priority.
Approach: review edge options and choose based on real usage (and support). Here, design and operations often matter more than catalog theory.

4) Staying on vSphere 8 due to compatibility

When it happens: legacy apps, hardware constraints, integrations, or a slow change calendar.
Approach: keep vSphere 8 (Standard/Enterprise Plus) and plan a transition to VVF/VCF when the business timeline allows it.

5) You need “serious” DR (demanding RPO/RTO)

Approach: this is rarely solved by “having backups”. You study the case and consider recovery/orchestration add-ons depending on your continuity strategy.

Key terms: portability, reporting, and support (what you should lock down)

On-prem vs cloud usage

Before buying, align one simple thing: where you will use it. Some bundles are primarily designed for on-prem, and if your goal is to move part of the workload to the cloud, you should validate the approach to avoid purchases that later “don’t fit”.

Compliance reporting: don’t leave it for “later”

In 9+ there is an approach to compliance reporting (usage/licensing) that should be built into operations. It’s not “paperwork”: it’s something you schedule, assign to an owner, and review periodically.

• Recommendation: create an operational reminder (for example, every 6 months) and document the procedure.
• Air-gapped environments: define from day one the reporting method for isolated environments.

Support and lifecycle

If you are still on vSphere 7, it’s important to review support and roadmap: planning upgrades reduces risk, avoids rushed decisions, and helps you buy with more margin.

How to buy with MSAdvance: process and checklist (so it works the first time)

Typical process

1. Discovery: inventory of hosts/CPU/cores, current version, and requirements (growth, DR, security).
2. Sizing: per-core calculation + validation of included vSAN vs required (and whether you need a TiB add-on).
3. Proposal: VVF/VCF/vSphere 8 options + add-ons, 1/3/5-year scenarios and recommendations.
4. Supply and activation: official licenses and guidance to make it operational without blockers.
5. Implementation (optional): deployment, health checks, and continuous improvement.

Request a VMware/Broadcom licensing quote

Common mistakes when buying per-core licenses (and how to avoid them)

• Counting threads as cores: licensing is by physical core. If you derived your count from vCPU, re-check.
• Forgetting the 16 cores/CPU minimum: the classic last-minute budget increase.
• Unreliable inventory: if you changed hardware or mixed generations, validate numbers before requesting pricing.
• Assuming included vSAN = usable vSAN: design (FTT/RAID/ESA/OSA) changes usable capacity.
• Not planning growth: buying “tight” gets expensive when you grow in 9–12 months.
• Leaving compliance reporting to the end: it should be part of operations from day 1.
• Not validating HCL and firmware: in virtualization, compatibility prevents long nights.

FAQ — buying VMware/Broadcom licenses

Official resources and external links (to verify terms)

• VVF SPD (current): terms, per-core metric, minimums, included vSAN and compliance reporting: Official VVF SPD page · PDF VVF_SPD_February2026
• VCF SPD (current): components, included vSAN, metric and compliance reporting: Official VCF SPD page · PDF VCF_SPD_February2026
• vSAN SPD (capacity subscription): Official vSAN SPD page · PDF VMware_vSAN_SPD_February2026
• Product Line Comparison (vSphere): official comparison of editions and availability: Official document
• Licensing overview (VCF/VVF): Broadcom TechDocs
• HCL (hardware compatibility): VMware Compatibility Guide

Related MSAdvance services: Software license procurement & sales · All services.

Conclusion: what to buy—and how to decide without regret

Buying VMware/Broadcom licenses today isn’t about “picking a name” (VVF or VCF)—it’s about aligning three things: real cores, vSAN capacity (included vs required), and operations (support, compliance, compatibility). When you do it right, the purchase is clear and TCO becomes predictable.

If you want, MSAdvance can help you turn inventory into a grounded, easy-to-defend proposal: what to buy, what it covers, what risks we avoid, and how we implement it.