VCF vs VVF: which bundle.

The two bundles in one view.

After the Broadcom acquisition, almost every VMware purchase resolves to one of two bundles. VMware Cloud Foundation (VCF) is the complete software-defined data centre stack; vSphere Foundation (VVF) is the compute-led bundle for organisations that do not need the full stack. Choosing correctly between them is the single largest lever a buyer controls on the bundle side of a Broadcom renewal, and Admodum, as an independent buyer-side advisory, exists to help make that choice on evidence rather than under sales pressure.

Both bundles are sold as a per-core subscription with the 16-core-per-CPU minimum that applies across the Broadcom model, set out in the pillar at Broadcom VMware licensing: VCF, VVF and per-core subscription and in detail at the 16-core-per-CPU subscription minimum. The bundle choice determines the per-core rate; the core count determines how many cores that rate is multiplied by. Both must be right for the renewal to be right.

What VCF includes.

VMware Cloud Foundation bundles the four pillars of a private cloud at a single per-core price: vSphere for compute virtualisation, vSAN for software-defined storage, NSX for software-defined networking and security, and the Aria suite for management, automation and operations.

The defining features of VCF are its inclusion of NSX and its generous vSAN allowance. NSX is VMware's networking and security product, providing virtual networking, micro-segmentation and software firewalling independent of physical network hardware; it is included only in VCF. The vSAN allowance in VCF is large enough that storage-heavy estates rarely need a separate add-on. For an organisation genuinely operating a software-defined data centre — using vSAN as primary storage and NSX as the network plane — VCF at a single per-core price can be cheaper than assembling the equivalent capability from VVF plus add-ons. The trap is paying VCF rates for NSX and vSAN capacity that sit idle.

What VVF includes — and caps.

vSphere Foundation provides vSphere compute virtualisation, vCenter management, a capped vSAN allowance and Aria operational tooling. It omits NSX and the full automation suite, which is precisely why it sits at a lower per-core price than VCF.

The critical number is the vSAN cap. VVF includes a vSAN allowance of around one tebibyte of capacity for every core licensed — a tebibyte being 2^40 bytes, slightly larger than a terabyte. For a compute-led estate with modest local storage this is ample. For a storage-heavy cluster it is not, and the shortfall must be met with a separately priced vSAN add-on stacked on top of the VVF subscription. This is the most common VVF surprise: a buyer right-sizes to VVF for the lower rate, then discovers that matching the estate's vSAN footprint requires add-ons that erode much of the saving. Modelling the vSAN requirement against the per-core allowance before committing is essential.

Which bundle fits which estate.

The decision is consumption-led, not aspiration-led. The question is not what the estate could one day run, but what it actually runs today and will run across the term.

An estate that uses only vSphere compute, with storage on a traditional SAN and networking on physical hardware, fits VVF, and paying for VCF would mean buying NSX and a large vSAN allowance that are never switched on. An estate that runs vSAN as primary storage and NSX as its network and security plane fits VCF, and trying to reconstruct that capability from VVF plus add-ons would usually cost more and complicate the architecture. The genuinely difficult cases sit in between: a compute-led estate with a single storage-heavy cluster, for example, where the right answer may be VVF across the estate with a vSAN add-on on the one cluster, rather than VCF everywhere.

The method that resolves all three cases is the same: produce a per-cluster map of what is actually consumed — compute only, compute plus vSAN, or the full stack with NSX — and price VCF against VVF-plus-add-ons for each. The lower total wins. This consumption mapping is the same discipline that drives the wider renewal, set out at how to read a Broadcom VMware renewal quote.

One further factor weighs on the decision: the direction of travel over the term. A bundle is fixed for the length of the subscription, so the choice should reflect not only today's consumption but a realistic view of the next two to three years. An organisation with a funded programme to adopt software-defined networking may rationally take VCF now to avoid a mid-term re-paper, while one with no such plan should not pay for NSX on the strength of a roadmap that may never be funded. The test is whether the wider stack is committed and dated, not merely aspirational. Where the future is genuinely uncertain, the shorter-term, lower-commitment route — VVF with add-ons as needed — preserves the option to revisit the bundle at the next renewal rather than locking spend against capability that may stay idle.

The add-on traps to avoid.

The bundle plus add-on structure creates two opposite mistakes, and a renewal can fall into either.

The first is over-bundling: defaulting to VCF when the estate only needs VVF, and paying the higher per-core rate across every core for NSX and vSAN capacity that are never used. This is the more common and more expensive error, because VCF is frequently the renewal's default framing, and because the difference compounds across every licensed core in the estate rather than appearing as a single line item that is easy to challenge. The second is under-bundling then over-adding: choosing VVF for the headline saving, then bolting on so many vSAN and other add-ons to cover real requirements that the total exceeds what VCF would have cost. Both are avoided by the same consumption map, priced both ways. A credible alternative platform strengthens the position further; the options are examined at VMware alternatives: Nutanix, Hyper-V, Proxmox and cloud, and the negotiation at the VMware renewal negotiation playbook. The wider engagement sits at the Broadcom / VMware practice, the reading list at the Broadcom knowledge hub and the cluster index at the Broadcom and VMware hub; engagement opens at contact.