vSAN vs Ceph on Proxmox VE

What you buy in vSAN after Broadcom

vSAN is VMware’s software-defined storage: host-local disks become a datastore vSphere can see. After perpetual licenses ended, a new purchase is a bundle subscription. vSphere Standard and Enterprise Plus (through 8 U3) do not include vSAN. VVF adds limited vSAN; the full HCI stack with vSAN is in VCF. You cannot “add vSAN” to inexpensive vSphere the way you once could.

On top of that: HCL hardware, 10/25 GbE and — in small installs — a witness. That is not a technical slight. It is cost and lock-in to stack against Ceph, which has no separate PVE price line. vSAN ESA is built around NVMe; OSA splits cache and capacity. Neither SKU can be “bolted on” to vSphere Standard after Broadcom — VMware HCI in practice means VVF or VCF.

What is built into Proxmox VE

Proxmox VE ships Ceph built in: VM disks on shared storage with snapshots, no separate licence. The cluster can be hyper-converged — the same servers hold the machines and the data. You do not pay Proxmox for a “Ceph licence”. You pay for disks, network and operator time. The optional PVE subscription (per socket) is hypervisor support, not a storage SKU.

Table: vSAN vs Ceph (RBD)

Live migration on shared storage copies memory, not the disk — that sentence is from the pvesm guide, not a slogan. Both vSAN and RBD give you that. The difference is entry cost and whether storage is a separate licensed entity.

Network, nodes and storage quorum

Production Ceph is stood up on at least three nodes. A separate storage network is operational standard — not a sales invention. vSAN also wants network and disk redundancy. Two servers plus a vSAN witness is a different conversation from two Proxmox nodes: hypervisor quorum (Cluster and quorum) does not replace a third storage node. With too few servers Ceph stops serving data — whether or not the Proxmox cluster still has votes.

When vSAN stays, when Ceph

• Ceph on PVE: a VMware move, HCI without a storage SKU, three or more nodes, an in-house team or a partner to run it.
• NFS / SAN instead of Ceph: the array already exists; you are not building a second SDS. PVE supports that (NFS, iSCSI, LVM on a LUN) — see storage selection.
• Keep vSAN: a short horizon, a VCF contract already paid, no appetite for a new SDS. That is a budget call, not a technical oracle.

vSAN capacity in VVF and VCF

In the VMware TCO write-up on this site, VVF includes limited vSAN (0.25 TiB per core) and VCF 1 TiB per core. vSphere Standard and Enterprise Plus (through 8 U3) do not include vSAN. “We’ll bolt vSAN onto cheap vSphere” is not a purchase path after Broadcom — that is why VMware HCI in practice means VVF or VCF, not ESXi plus a separate SKU.

Ceph on PVE has no such TiB/core meter. You pay for disks, network and operator time. The limit is physical (space, network, rebuild time), not contractual.

Network and failure domains

The storage network stays separate from the cluster and live-migration networks. Mixing them is a classic way to stall during a disk rebuild or to lose hypervisor quorum during an “innocent” VM move.

Failure domains (server, rack) are the analogue of vSAN policies, not an FTT checkbox. Mapping “FTT=1 → three copies” 1:1 is a design shortcut, not a VMware or Ceph spec — we check node count before promising the same survival. Disk layer: ZFS, LVM, NFS, Ceph.

HCI or dedicated storage

Proxmox VE allows both: disks on the same servers as the VMs (fewer racks, rebuilds share CPU with production) or a separate storage shelf (more cost, but rebuilds do not starve VMs). In both variants the storage network stays separate, and production Ceph still counts from three nodes — not from two with a QDevice.

Ceph needs spare capacity for rebuild. Filling “to the last percent” is how a disk failure becomes an outage. vSAN has its own occupancy thresholds; we do not copy them 1:1. Cluster tuning belongs in the implementation — here the decision is HCI, dedicated Ceph, or the array that already stands.