Rob Pankow 
Broadcom’s 2023 acquisition of VMware® introduced subscription-only licensing for vSAN and vSphere, and the contract structure changed in ways that matter for storage economics in particular. The free VMware Foundation tier covers basic virtualization but not vSAN. To keep vSAN running you now choose between VMware Cloud Foundation (VCF) at roughly $350 per core per year or VMware vSphere Foundation (VVF) at roughly $175 per core per year. In both cases, the billing unit is a CPU core on every server in the cluster, regardless of whether that server is primarily compute or primarily storage.
That billing model creates a compounding problem for teams considering a Kubernetes migration or a platform refresh: every new host added to the cluster adds to the license invoice. A team that was running vSAN on a fixed three-year enterprise license agreement now faces an annualized cost that scales directly with headcount in the cluster. This guide models that cost concretely, identifies what the per-core figure omits, and explains how disaggregated storage changes the math.
Why Broadcom Changed the vSAN Cost Equation
Before the Broadcom acquisition, vSAN licensing was a per-socket fee bundled into vSphere or purchased as an add-on. Per-socket pricing was predictable: a two-socket server cost two licenses regardless of core count, and many enterprise agreements fixed the total cost for three years. Customers who completed purchases before the acquisition deadline effectively locked in legacy pricing.
Under Broadcom’s model, the unit is a physical CPU core. A dual-socket server with two 32-core processors contributes 64 billable cores. That same server counts the same whether it runs storage-heavy VMs or mostly idle compute. There is no licensing discount for nodes that use less than their allocated storage capacity, and there is no option to exclude storage-only nodes from compute licensing or vice versa. Hyperconverged infrastructure couples compute and storage licensing by design.
Platform migrations away from VMware have been accelerating. Infrastructure teams are now actively computing the migration ROI before the next renewal cycle locks in another three years of per-core pricing. That window, before a renewal, is when the cost math is most visible and when the platform decision has the most leverage.
The 200-Core Cost Model: VCF, VVF, and Disaggregated NVMe/TCP
A 200-core vSAN cluster is a representative mid-size deployment: roughly five to eight dual-socket servers with modern 20 to 32 core processors, running a mix of VMs and potentially Kubernetes workloads on vSphere.
| Licensing option | License unit | Annual software cost (200 cores) | Key characteristics |
|---|---|---|---|
| VMware Cloud Foundation (VCF) | ~$350/core/yr | $70,000/yr | Includes vSAN Advanced, vSphere, NSX, Aria; scales with every core added |
| VMware vSphere Foundation (VVF) | ~$175/core/yr | $35,000/yr | Includes vSAN Standard; Advanced features require VCF; still per-core |
| simplyblock disaggregated NVMe/TCP | per usable TB/yr (no per-core fee) | scales with capacity provisioned, not core count | Any hypervisor or bare-metal; predictable capacity-based licensing; no vCenter dependency |
| Ceph via Red Hat® (ODF / Red Hat Ceph Storage) | per-node or per-TB Red Hat subscription | varies; Red Hat Ceph Storage is priced per physical node/yr | Upstream Ceph is open-source, but enterprise deployments typically require Red Hat Ceph Storage or OpenShift Data Foundation subscriptions for support; significant admin overhead regardless |
Table 1: Licensing model comparison for storage software on a 200-core cluster. Hardware costs excluded from all rows. For simplyblock, the cost depends on usable TB provisioned rather than host count. Ceph upstream is free to use but unsupported; Red Hat subscriptions add cost at enterprise scale.
The hardware cost is not zero in any scenario. The difference is in the licensing structure. Under VCF, $70,000 per year in perpetuity pays for the right to use software on hardware you already own, and that cost grows with every core you add. Simplyblock’s license is capacity-based: you pay for the usable storage TB you provision, not for the number of CPU cores in the cluster. That means a compute-heavy scale-out does not increase the storage license bill, and a storage-heavy expansion does not affect the compute budget.
Over a three-year horizon, VCF software licensing at 200 cores costs $210,000 before any hardware refresh. VVF costs $105,000. Both figures assume the core count stays flat. If the cluster grows by 50 cores during that window, add $52,500 (VCF) or $26,250 (VVF) to the total.
What the Per-Core Number Does Not Capture
The license fee is the most visible cost, but total cost of ownership includes several factors that the per-core line item does not represent.
Hyperconverged node tax. vSAN requires a minimum host count (typically three nodes for standard vSAN, four for stretched clusters), and each host must carry both compute and storage roles. You cannot add a storage-only node to absorb growing data volume without also adding compute capacity you may not need. The reverse is also true: scaling compute means provisioning additional storage capacity and paying the per-core fee on those new nodes. A 20-node cluster where 15 nodes are compute-heavy and 5 are storage-heavy still pays licensing on all 20 nodes.
vCenter operational dependency. vSAN management is integrated with vCenter Server. Running vSAN without vCenter is unsupported. That dependency persists at the management layer even when the workload preference shifts toward Kubernetes. Teams running Red Hat® OpenShift® or Kubernetes on vSphere pay for vCenter to keep the storage layer operational even while the virtualization layer is being phased out.
Specialized admin requirement. vSAN configuration, stretch cluster setup, fault domain management, and witness appliance configuration require certified VMware administrators. In a platform transition where the Kubernetes team and the vSphere team are different people, the storage layer remains in the hands of the VMware team regardless of which platform is running the workloads. That organizational dependency is not in the per-core invoice.
Capacity efficiency at scale. vSAN’s deduplication and compression features work at the cluster level and have specific hardware requirements. For vSAN ESA (the newer architecture), all-NVMe nodes are required to activate efficiency features. Effective usable capacity after protection overhead, deduplication rates, and mandatory slack space can be well below the raw capacity of the drives. Efficiency gains are highly workload-dependent and difficult to model in advance.
Hypervisor lock-in. vSAN is vSphere-only. If any part of the platform shifts to a different hypervisor, bare-metal Kubernetes, KubeVirt, or Red Hat® OpenShift® Virtualization, the storage layer does not follow. Teams running mixed-hypervisor environments or planning a multi-year transition from vSphere to Kubernetes-native infrastructure carry the vSAN dependency as dead weight until the migration is complete. Disaggregated NVMe/TCP storage is hypervisor-agnostic: the same storage cluster serves vSphere VMs, KubeVirt pods, and bare-metal Kubernetes workloads simultaneously over the same NVMe/TCP fabric, without re-provisioning volumes or changing the storage architecture mid-migration.
Limited-time vSAN migration promotion — ends 30 Sep 2026 New customers migrating from vSAN receive up to 1 PB of storage capacity at no charge in year one. 3-year minimum term. $50k/yr minimum contract value. See promotion terms or talk to a storage architect
Disaggregated NVMe/TCP as the Storage Migration Path
Disaggregated storage separates the storage layer from the compute layer entirely. Storage nodes hold NVMe drives and serve block volumes over NVMe/TCP, an open protocol that runs over standard Ethernet. Compute nodes mount those volumes through the NVMe/TCP host driver and a CSI driver: the same interface Kubernetes uses for any block volume.
The key operational difference from vSAN is that the two layers scale independently. If workloads are growing in data volume but not in compute, storage nodes are added without touching the compute cluster. If the cluster needs more CPU capacity for AI inference or batch processing, compute nodes are added without adding storage capacity. Neither expansion triggers licensing cost on the other layer.
For Kubernetes and OpenShift environments specifically, disaggregated storage enables something vSAN cannot: pod scheduling freedom. A Kubernetes pod backed by an NVMe/TCP volume can reschedule to any node in the cluster when its original node drains for maintenance. The volume reattaches over the network. With vSAN local storage or directly attached NVMe, the pod is pinned to the node where the disk lives. See the simplyblock vs. vSAN architecture comparison for a deeper treatment of these differences, and replacing vSAN storage on OpenShift and Kubernetes for the migration path.
| Decision criterion | Stay on vSAN | Switch to disaggregated NVMe/TCP |
|---|---|---|
| Primarily VMware-native workloads, no Kubernetes migration planned | Reasonable | Low ROI for the switch |
| Kubernetes or OpenShift is primary or growing platform | High per-core license overhead for the storage layer | Strong operational and cost fit |
| Cluster grows in storage volume but not in compute (or vice versa) | Both layers must scale together, cost grows with cores | Scale each layer independently; storage cost tied to capacity, not cores |
| Mixed hypervisors or bare-metal Kubernetes in the environment | vSAN restricted to vSphere only | Same storage cluster serves all hypervisors and bare-metal nodes |
| VMware-certified admins available; Kubernetes storage expertise limited | Lower transition risk | Ramp-up investment required |
| vSAN renewal approaching | Locks in per-core pricing for 3 more years | Window to evaluate before the commitment resets |
Table 2: Storage platform decision criteria for teams currently operating vSAN.
The migration path for most teams is phased: disaggregated NVMe storage is introduced as a new tier alongside the existing vSAN deployment, serving new Kubernetes persistent volumes while vSAN continues serving legacy VMs. Workloads migrate to the new storage layer progressively over six to eighteen months, rather than a single cutover. For more detail on how simplyblock fits into a best vSAN alternatives shortlist alongside other options, that post covers the full competitive landscape.
Questions and Answers
What is the actual cost of vSAN under Broadcom’s current licensing model?
VMware Cloud Foundation (VCF), which includes vSAN Advanced, is priced at approximately $350 per physical core per year. VMware vSphere Foundation (VVF) is approximately $175 per core per year and includes vSAN Standard. Both are subscription-only; perpetual license options for new contracts are no longer available. A 200-core cluster costs $70,000 per year under VCF and $35,000 per year under VVF in software licensing alone, before hardware, support contracts, or add-on integrations.
Can disaggregated NVMe/TCP storage replace vSAN for VMware VM workloads?
Yes, when the environment is transitioning to KubeVirt, OpenShift Virtualization, or another Kubernetes-native VM platform. Disaggregated NVMe/TCP storage integrates with these platforms via CSI, providing RWO and RWX block volumes with snapshot, cloning, and expansion capabilities that match what vSAN provides in the VMware stack. For environments planning to stay on vSphere as the long-term platform, vSAN’s integration with vCenter remains the lower-risk choice.
How is simplyblock licensed compared to vSAN?
Simplyblock is licensed per usable storage TB provisioned, not per CPU core or per socket. That means the storage license cost scales with how much data you store, not with how many servers are in the cluster or how many cores each server carries. For teams running compute-heavy workloads where storage capacity grows more slowly than compute headcount, this model is substantially cheaper than vSAN’s per-core billing. For storage-heavy workloads, the predictability still holds: you know the cost per TB before provisioning, without needing to count cores across the cluster.
How does simplyblock compare to Ceph for replacing vSAN?
Upstream Ceph has no license fee, but that is not the full picture for enterprise deployments. Most production Ceph environments run with Red Hat® Ceph Storage or OpenShift® Data Foundation subscriptions, both of which carry per-node or per-TB Red Hat support costs. Those subscriptions exist because self-managed Ceph at scale requires Ceph-certified administrators, and the operational complexity of rebalancing, placement group management, and CRUSH map tuning is high enough that most teams either pay for Red Hat support or understaff the operation and absorb the risk. The licensing cost is lower than vSAN in most cases, but it is not zero. Simplyblock’s model is predictable capacity-based pricing with a much simpler operational surface: no placement groups, no CRUSH maps, no dedicated Ceph admin role. Ceph is a reasonable choice for teams that already have deep Ceph expertise and are optimizing for upfront cost over operational simplicity. Simplyblock fits better when NVMe latency, day-2 simplicity, and hypervisor-agnostic deployment are the priorities.
Does switching to disaggregated storage require replacing the entire VMware environment at once?
No. Disaggregated storage can be introduced as a new storage tier alongside an existing vSAN deployment, serving new workloads or Kubernetes PVCs while vSAN continues to serve legacy VMs. A phased migration moves workloads to the new storage layer progressively, rather than a single cutover. This is the most common pattern for teams running a hybrid VMware plus Kubernetes platform during a multi-year migration program, and it aligns naturally with the renewal cycle: new workloads avoid the per-core fee from day one while existing VMs remain stable until they are migrated or decommissioned.
