Want to buy VVF 9 with correct core counting and no surprises?
At MSAdvance, we supply and sell VMware vSphere Foundation (VVF) 9. We help you translate per-core licensing into a clean bill of materials, understand the included vSAN entitlement (0.25 TiB/core), and prepare a purchase that makes sense for your infrastructure.
- Exact core calculation per host and per CPU (including the 16-cores-per-CPU minimum).
- vSAN sizing: what the “included” entitlement covers and when it makes sense to add vSAN by TiB.
- 1/3/5-year scenarios and recommendations to align renewals and reduce admin overhead.
Request a proposal See software license procurement & sales
If you prefer, here’s a general guide to get oriented before deciding: Buy VMware/Broadcom licenses by core (VVF/VCF/vSAN).
VVF 9 is purchased as a per-core subscription: you license the hosts’ physical cores, with a minimum of 16 cores per CPU (even if your CPU has fewer). It includes vSAN as a licensing entitlement of 0.25 TiB per licensed core (poolable within VVF). It’s a very solid option for on-prem virtualization when you want a complete package (vSphere + vCenter + base operations + Kubernetes) without moving up to the full VCF stack.
Executive summary — what matters before buying VVF 9
- The metric is per core: count physical cores, not threads. Apply the 16-cores-per-CPU minimum.
- BIOS-disabled cores still count: the calculation is based on the physical hardware.
- vSAN included: VVF grants 0.25 TiB per core as a license entitlement (usable capacity depends on design).
- VVF includes vSphere (bundle equivalent at an “Enterprise” level), vCenter, base operations/Aria, and Kubernetes services.
- If you need NSX and full-stack governance, you’re typically looking at VCF 9.
- Standalone vSphere (Standard/Enterprise Plus) stays on the v8 branch (per current program and documentation).
- Compliance / reporting: there are mandatory, verifiable reporting obligations in the v9 family. Don’t leave this “for later”.
- A good purchase doesn’t start with “price”: it starts with inventory, correct core counts, growth, and storage design.
1. What VMware vSphere Foundation (VVF) 9 is and when it makes sense
Simple idea: VVF 9 is the “complete package” for on-prem virtualization: vSphere + vCenter + base operations + Kubernetes, plus a per-core vSAN entitlement.
VVF 9 is designed for organizations that want to keep (or modernize) on-prem virtualization with a consistent bundle that’s easier to manage than buying each component separately. In practice, it’s a great fit if:
- Your priority is to virtualize well (servers, applications, VMs) with a solid foundation and official support.
- You want centralized management with vCenter and a base operations/monitoring layer without building a puzzle.
- You’re interested in vSAN but don’t want to commit to large capacity purchases before you know how you’ll grow.
- You like keeping the door open for Kubernetes (even if it’s not “for tomorrow”).
On the other hand, if your scenario requires advanced networking and security at scale from day one (for example, micro-segmentation and complex overlays), end-to-end platform lifecycle automation, or a highly structured hybrid-cloud private cloud approach, the natural candidate is usually VMware Cloud Foundation (VCF) 9.
If you want on-prem virtualization done right with a bundle that already includes the “essential advanced” building blocks (plus a base vSAN entitlement), VVF typically fits. If you’re building a full SDDC stack with networking/security and lifecycle automation as top priorities, VCF typically fits.
2. How VVF 9 is licensed: per-core metric (with clear examples)
The best way to avoid mistakes: count physical cores (not threads), apply the 16-cores-per-CPU minimum, and don’t forget BIOS-disabled cores.
The base rule for VVF 9 is easy to say but easy to mess up if you calculate in a rush: you license per physical core on the hosts running vSphere.
- Minimum 16 cores per CPU: if a CPU has 12 cores, you license 16. If it has 24, you license 24.
- Count physical cores, not threads: Hyper-Threading is not licensed as additional cores.
- Include BIOS-disabled cores: if the hardware has X physical cores, they’re part of the calculation.
Quick example (typical)
You have 3 hosts. Each host has 2 CPUs with 24 cores each. Then:
- Cores per host = 2 CPUs × 24 cores = 48 cores
- Total cores = 3 hosts × 48 = 144 cores
- Result: you license 144 cores of VVF 9
Quick checklist to get the calculation right
- List your hosts and CPUs per host.
- Confirm physical cores per CPU (don’t confuse cores with threads).
- Apply the 16-cores-per-CPU minimum.
- Multiply and sum: CPUs × cores × hosts.
- Check for any hosts “outside the cluster” that also run vSphere (very common).
Practical tip: if there’s any doubt, work from an exported inventory (vCenter), a hardware spreadsheet, or the vendor BOM. “I think it was 20 cores” is how you end up with a poorly sized purchase.
3. What VVF 9 includes (and what it does not)
In short: VVF 9 bundles vSphere + vCenter + base operations/Aria + Kubernetes, and adds vSAN per core as a license entitlement.
| Product | Metric | What it includes | When it fits |
|---|---|---|---|
| VMware vSphere Foundation (VVF) 9 | Per core (min. 16/CPU) | vSphere (bundle at an “Enterprise” level), vCenter, vSAN 0.25 TiB/core, base operations/Aria, and Kubernetes services. | Serious on-prem virtualization with a complete bundle and a base vSAN entitlement included. |
| VMware Cloud Foundation (VCF) 9 | Per core (min. 16/CPU) | vSphere + vSAN (bundle reference: 1 TiB/core), NSX, advanced operations, and full platform lifecycle management. | When you need the full stack (network/security plus platform automation and governance). |
| vSAN Add-on (capacity) | Per TiB | Extends licensed capacity when the included entitlement is not enough. | When data grows without adding cores (or when the design requires more licensed capacity). |
| vSphere 8 (Standard / Enterprise Plus) | Per core (min. 16/CPU) | Standalone editions on the v8 branch (per availability and program rules). | Specific compatibility needs or continuity on v8; for v9, the typical path is VVF/VCF. |
What does VVF 9 NOT include?
The most important clarification to avoid buying with the wrong expectations: VVF is not VCF. If you need full NSX (advanced network/security at large scale), or you want an end-to-end private-cloud platform with full lifecycle management, that’s typically VCF territory.
4. VVF 9 vs VCF 9 vs vSphere 8: how to choose without overthinking
Mental shortcut: VVF = complete on-prem virtualization bundle. VCF = complete SDDC platform. vSphere 8 standalone = continuity/compatibility on the v8 branch.
| Area | VVF 9 | VCF 9 | vSphere 8 (Std/Ent+) |
|---|---|---|---|
| Focus | On-prem virtualization bundle | Full SDDC platform (full stack) | Standalone edition (v8 branch) |
| Management | vCenter | Platform management (more complete) | vCenter |
| vSAN | 0.25 TiB/core included | 1 TiB/core (bundle reference) | Optional (add-on) |
| Networking/Security | Advanced baseline (vSphere) | NSX and broader capabilities | Standard features by edition |
| Operations | Base operations/Aria | More advanced operations | By edition and add-ons |
| When to choose | On-prem with strong cost/value balance | Full platform for more demanding requirements | Compatibility/continuity on v8 |
If your main criteria are cost and simplicity (without giving up a robust base), VVF often wins. If your main criteria are full-stack platform governance (especially networking/security and lifecycle automation), VCF often wins.
Recommended reading on MSAdvance: Buy VCF 9 · Buy vSphere Standard · Buy vSphere Enterprise Plus v8 U3
5. Step-by-step core calculation + included vSAN (0.25 TiB/core)
The formula: cores to license (with 16/CPU minimum) + included vSAN = licensed cores × 0.25 TiB.
5.1 Core formula (with 16/CPU minimum)
For each host:
Cores to license per host = Σ (max(physical_cpu_cores, 16) × number_of_cpus)Then sum across all hosts.
5.2 Included vSAN formula inside VVF
Included vSAN (TiB) = Licensed VVF cores × 0.25| Scenario | Cores/CPU | CPUs/host | Hosts | Cores to license | Included vSAN (0.25 TiB/core) |
|---|---|---|---|---|---|
| Basic ROBO | 16 | 1 | 2 | 32 | 8 TiB |
| Mid-size cluster (3 nodes) | 24 | 2 | 3 | 144 | 36 TiB |
| Dense HCI (4 nodes) | 32 | 2 | 4 | 256 | 64 TiB |
| Growth plan (6 nodes) | 28 | 2 | 6 | 336 | 84 TiB |
| VDI/Edge (2 nodes) | 20 | 1 | 2 | 40 | 10 TiB |
If the included entitlement doesn’t cover what you need, there are two common paths:
- Add vSAN by TiB (when data grows but you don’t want to increase cores).
- Revisit architecture (for example, if resiliency design is consuming too much usable capacity).
If you want to go deeper on vSAN (included entitlement vs add-on), here’s a dedicated guide: Buy vSAN by TiB.
6. vSAN: “included” license entitlement vs real-world usable capacity
Important: 0.25 TiB/core is a license entitlement. Usable capacity depends on design (failures to tolerate, RAID, compression/dedupe, etc.).
This is where many people get surprised: licensed capacity is not the same as usable capacity. The license grants an entitlement in TiB per core, but what you can actually use depends on your storage policies and architecture.
6.1 Factors that strongly affect usable capacity
- Failures to tolerate (FTT): higher protection requires more replication/parity.
- RAID type and storage policy: this changes disk efficiency.
- Annual growth: growth is often underestimated (logs, backups, VDI, files, databases).
- Performance (IOPS): sometimes the limit is not capacity—it’s performance and latency.
“I have 36 TiB included, I’m fine.” Then you adopt a safer policy (or increase FTT), and usable capacity drops significantly. Result: the license entitlement was correct, but the design needed more disks (or an add-on). That’s why it’s worth sizing properly before you buy.
6.2 When you typically need vSAN by TiB (add-on)
- When data grows quickly and you won’t add hosts/cores in the short term.
- When resiliency/performance design substantially reduces usable capacity.
- When you want comfortable headroom for upcoming projects (VDI, databases, analytics, etc.).
Want us to review your inventory and tell you how many cores and how much capacity you should buy?
With a small set of inputs (hosts, CPUs, cores, and an estimate of growth), we can help you translate this into a realistic purchase: what VVF 9 covers, how much the included vSAN entitlement gives you, and whether you should add vSAN by TiB.
Request a sizing review & proposal Software license procurement for businesses
7. Typical buying scenarios (practical recommendations)
Goal: recognize your situation and know what to do next—without losing weeks.
7.1 SMB / mid-market: classic virtualization + moderate HCI
Profile: 3–4 hosts, mixed workloads, lean IT team, stability required.
Recommendation: VVF 9 often fits because it balances cost and capability: you get a complete bundle and a base vSAN entitlement.
If data grows, add vSAN by TiB without disrupting your strategy.
7.2 Environment with demanding networking/security and automation
Profile: enterprise, segmentation, strong network control, and a focus on lifecycle automation.
Recommendation: consider VCF 9 if NSX and full-stack governance are truly required.
7.3 ROBO / Edge (2 nodes) with controlled cost
Profile: small branch sites, edge environments, local continuity.
Recommendation: VVF 9 can be a strong base, but design matters more here:
capacity, resiliency, and workload type (because margins are tighter).
7.4 Staying on vSphere 8 for compatibility
Profile: hardware/app compatibility constraints or a limited change window.
Recommendation: stay on v8 when needed, but with a roadmap:
when you move to VVF/VCF, what hardware changes, and how you avoid getting “stuck” without a plan.
7.5 DR and business continuity (when licensing is not the only variable)
Profile: clear RPO/RTO targets, periodic tests, orchestration requirements.
Recommendation: beyond licensing, define your DR approach (secondary site, storage, networks, testing).
In some cases, this is complemented with specific add-ons depending on strategy.
8. Key terms & compliance (reporting): what to prepare
Business translation: it’s not just “buy and done”. There are reporting obligations and best practices you should lock in from day one.
8.1 Subscription and terms
In practice, VVF is consumed as a subscription. Many purchases use common terms (for example, 1/3/5 years), and what IT/Finance typically wants is aligned renewals (so you’re not managing different renewal dates every couple of months).
8.2 Intended use: on-prem and “cloud-like” scenarios
VVF is oriented to internal, on-prem use. If your setup is “cloud-like” (for example, dedicated colocation), the key is to match the program definitions and not assume “anything goes”. If you’re a service provider or you plan to offer infrastructure to third parties as a service, review the case before buying.
8.3 Compliance reporting: the part you shouldn’t ignore
In the v9 family, there are mandatory verifiable reporting obligations at defined intervals. Put simply: if you ignore it, you can lose access to parts of the software, updates, and support.
How to prepare without overcomplicating
- Assign a named owner (IT/platform) and a backup person.
- Set a recurring reminder (don’t rely on memory).
- Document where reports are generated and what evidence you retain for internal audit.
- If hosts/CPUs change during the year, review the impact on core counts and reporting.
9. How to buy with MSAdvance (process & checklist)
The idea: keep it simple for you: you provide minimal inputs, and we return a clear proposal you can defend to IT and Finance.
9.1 Process (step by step)
- Discovery: inventory of hosts/CPUs/cores, versions, growth, and real needs (capacity, performance, resiliency).
- Sizing: core calculation and analysis of included vSAN vs vSAN add-on by TiB if needed.
- Proposal: VVF 9 (and if relevant, comparison to VCF 9 or continuity on vSphere 8), with clear options.
- Supply & activation: delivery of official licenses and a practical onboarding/best-practices guide.
- Optional: implementation, health-check, and ongoing guidance (if you want it end-to-end).
| Area | What to verify | OK |
|---|---|---|
| Inventory | Hosts, CPUs, and verified physical cores (don’t confuse with threads) | □ |
| Minimums | Applied the 16 cores per CPU minimum | □ |
| vSAN | Calculated included TiB (0.25/core) and growth headroom | □ |
| Architecture | Resiliency and performance policies defined (to estimate usable capacity) | □ |
| Compatibility | Hardware validated in the HCL / Compatibility Guide | □ |
| Compliance | Reporting owner and routine defined | □ |
| Renewals | Dates aligned (if there are multiple subscriptions) | □ |
You can also view our software license procurement & sales service for businesses.
10. Common mistakes when licensing per core (and how to avoid them)
10.1 Counting “threads” instead of cores
The classic. Licensing is based on physical cores. If someone sends you a screenshot with “vCPU” or “threads”, you can’t use that directly for licensing.
10.2 Forgetting the 16-cores-per-CPU minimum
CPUs with 8, 10, or 12 cores still require licensing 16. In small environments, this detail can materially change the budget.
10.3 Underestimating vSAN because “it’s included”
Included does not mean unlimited. Calculate included TiB, then translate it to usable capacity using your real-world design. Otherwise, you end up buying later—under pressure.
10.4 Buying without checking compatibility (HCL)
You can have perfect licenses… and an unsupported platform due to a driver/firmware mismatch. This becomes painful when you need to open a support case.
10.5 Ignoring reporting until it’s too late
If you don’t assign ownership and routines from the start, it becomes “no one’s job”. And when the problem arrives, it arrives with real impact (updates/support).
10.6 Not planning for growth (only looking at “today”)
Most platforms don’t grow linearly: they jump (projects, retention, logs, backups, VDI, etc.). If you buy with zero headroom, you’ll typically be buying again in 6–12 months.
11. Frequently asked questions (FAQ) — buy VVF 9
Does VVF 9 include vSAN “for real” or is it a demo?
It’s a license entitlement included in the bundle: 0.25 TiB per licensed core under VVF. Usable capacity depends on your design (resiliency policies, RAID/policies, etc.).
How exactly are cores counted?
You license the hosts’ physical cores, with a minimum of 16 cores per CPU. Don’t confuse cores with threads (Hyper-Threading). Also note: BIOS-disabled cores are included in the calculation.
If I have 12-core CPUs, can I license 12?
No. The 16-cores-per-CPU minimum applies. In that case, you’d license 16 per CPU.
Can I add more vSAN if I run short?
Yes. You can purchase vSAN by TiB (add-on) when the included entitlement isn’t enough or when you need growth headroom.
Is VVF for public cloud?
VVF is oriented to on-prem use. If your scenario involves third-party service delivery or a full platform portability/hybrid approach, you typically review the program terms and evaluate VCF or other options per the current program.
What if I change hardware (CPUs/hosts) during the subscription?
If physical cores change on the licensed hosts, your calculation can change. Treat it as a managed change: update inventory, assess licensing impact, and keep evidence for compliance and internal audit.
Why is “reporting” such a big topic in v9?
Because it’s not minor: there are verifiable reporting obligations at program-defined intervals. If you don’t comply, you may lose access to parts of the software and face limitations on updates/support.
Can you help with licensing even if my team handles implementation?
Yes. We can support core counting, included vSAN vs add-on estimation, and a clear purchase proposal, and your team can implement if that’s your preference.
12. Official resources and external links
- VVF SPD (program documentation): VMware vSphere Foundation (VVF) SPD (Broadcom)
- VCF SPD (for comparison): VMware Cloud Foundation (VCF) SPD (Broadcom)
- vSphere product line comparison: Official document
- VMware Licensing Glossary: Official glossary
- Hardware Compatibility Guide: Compatibility Guide (Broadcom)
Related internal links (MSAdvance): Core-based guide (VVF/VCF/vSAN) · Buy VCF 9 · Buy vSAN by TiB · Software license procurement
13. Conclusion: the next step to buy VVF 9 with confidence
Buying VMware vSphere Foundation (VVF) 9 is best done with real numbers on the table: actual physical cores (with the 16/CPU minimum), growth, and a serious look at how vSAN will behave in your design. Once those are clear, purchasing becomes straightforward: choose the term, organize reporting, and ensure the platform is supported.
Want a fixed-scope proposal to buy VVF 9?
At MSAdvance we can help you calculate cores, validate the included vSAN entitlement (0.25 TiB/core), and build a defensible purchase proposal for IT and Finance.
