When Broadcom completed its acquisition of VMware in late 2023, the licensing model changed significantly. The old perpetual per-CPU model was gone. In its place came two subscription tiers: VMware vSphere Foundation (VVF) and VMware Cloud Foundation (VCF). If you’ve been trying to figure out which one matters for your environment, or you’re studying for a certification and need to understand the difference in practice rather than on paper, this series is for you.
This is Part 1. It covers what VVF actually is, what it includes, how the licensing works, and why it’s worth building a lab around. Parts 2 and 3 walk through the actual deployment.
What Is VMware vSphere Foundation?
VMware vSphere Foundation is a subscription licence that bundles the core VMware compute and storage stack into a single per-core entitlement. It’s positioned as the option for organisations that want enterprise-grade virtualisation and software-defined storage without the full automation and orchestration overhead of VCF.
According to Broadcom’s official documentation, a VVF subscription includes:
- vCenter Server
- ESXi
- vSphere IaaS control plane
- vSAN
- VMware Aria Operations
- VMware Aria Operations for Logs
- VMware Aria Suite Lifecycle
- VMware Aria Automation Orchestrator (Basic)
That’s a meaningful bundle. You’re not just getting ESXi and vCenter — you’re getting vSAN for software-defined storage, Aria Operations for monitoring, and Aria Ops for Logs for log aggregation. A single subscription covers all of it.
In the vSphere Client, the VVF solution licence shows up as “vSphere 8 Enterprise Plus for vSphere Foundation”. Worth knowing when you’re looking at your licence inventory and wondering why the name doesn’t match what’s on the Broadcom portal.
How the Licensing Model Works
VVF uses a per-core subscription model. You’re paying per physical CPU core across your ESXi hosts, with a minimum of 16 cores licensed per CPU socket. That minimum is important for small deployments. If your host has a single 8-core CPU, Broadcom still counts it as 16 cores for licensing purposes.
A quick example from the official docs: one ESXi host, one CPU, eight cores — you need to licence 16 cores because that’s the minimum per CPU. Two hosts, two CPUs each, eight cores per CPU — that’s 64 core licences total (four CPUs × 16 cores minimum per CPU).
The solution licence assigns to vCenter Server and ESXi hosts. Once assigned to the ESXi hosts in a vSAN cluster, vSAN is licensed automatically — there’s no separate vSAN licence key to manage.
For a lab, the 60-day evaluation mode covers all features, which is enough time to build a complete VVF environment, run through the scenarios you want to test, and document what you’ve learned.
VVF vs VCF: What’s Actually Different
This is where people get confused, so it’s worth being precise.
VVF gives you the compute and storage layers: ESXi, vCenter, vSAN. You deploy them yourself, configure them yourself, and manage their lifecycle yourself. There’s no automated bringup process, no prescriptive architecture to follow, and no centralised orchestration engine overseeing the stack.
VCF adds SDDC Manager on top of that. SDDC Manager is the orchestration appliance that automates the initial bringup from a JSON specification, manages the lifecycle of every component in the stack (patches, upgrades, certificate rotation), and integrates NSX for network virtualisation. VCF is a validated, integrated stack — Broadcom certifies that specific versions of vCenter, ESXi, vSAN, and NSX work together, and SDDC Manager maintains that validated state over time.
The practical difference in a lab context:
- A VVF lab takes roughly an hour from blank ESXi hosts to a running vSAN cluster. You can build it on a single physical host.
- A VCF lab requires four management hosts as a minimum viable cluster, a JSON bringup file, SDDC Manager, and an NSX deployment. Realistically you need 256 GB of RAM on your physical host to run it nested, and the bringup process takes two to three hours on its own.
VVF is not a cut-down version of VCF. It’s a different product with a different operational model. A lot of customers, particularly mid-market and SMB, run VVF because they don’t need the automation framework — they have a small enough environment to manage manually and want to keep operational complexity low. Knowing VVF inside out is directly applicable to what a large portion of VMware’s installed base is actually running.
Why Build a Lab Around VVF?
When I started thinking about what to build next in my home lab, VVF made sense for a few reasons.
First, it’s what a lot of customers are migrating to. Post-acquisition, organisations that were on perpetual vSphere licences are evaluating whether to move to VVF or VCF. The migration path, the feature gaps, the licence cost implications — these are real conversations happening right now. Having hands-on experience with VVF means you can speak to that decision from something other than a datasheet.
Second, vSAN is included. Understanding vSAN — how disk groups work (OSA), how the flat storage pool works (ESA), how failures affect availability, how resync behaves — is genuinely useful knowledge. You don’t need a separate storage array or a complicated iSCSI setup to build a shared storage cluster. Three hosts with some NVMe disks and vSAN does the job.
Third, the resource requirements are manageable. My lab runs on a single Dell R740xd with two Xeon Gold 6230 CPUs — 40 physical cores, 80 threads, and enough RAM to run three nested ESXi hosts comfortably. VVF doesn’t need the hardware headroom that VCF does, so a single capable server is enough to build and document the full stack.
There’s also the certification angle. The VMware VCP-DCV exam covers vSAN, vSphere HA, DRS, and the core vCenter workflows that VVF is built around. Building a lab and actually breaking things is a better preparation than reading through study guides.
What This Series Covers
This series follows the full VVF deployment from nothing to a working cluster:
- Part 1 (this post): What VVF is and why it’s worth labbing.
- Part 2: Licensing, downloads, and what you need before touching the installer.
- Part 3: Deploying vCenter and building the vSAN cluster from scratch.
The lab runs nested on a single physical host. The network design uses VLANs to separate management, vMotion, and vSAN traffic — the same pattern you’d use in a real deployment. Everything in this series is stuff I’ve actually done on my hardware, so the specifics (IP addresses, hostnames, VLAN IDs) reflect what’s running in my lab rather than a hypothetical architecture.
If you’ve been meaning to get hands-on with the post-acquisition VMware stack but weren’t sure where to start, VVF is the right entry point.