Open-source alternative to VMware vSAN

How vSAN capabilities map to Ceph and Proxmox VE

This table compares the main vSAN capabilities with the Ceph interfaces and Proxmox VE storage options that cover them. Read each row as a question to answer in your own environment: where a capability is covered directly, where it is covered by a different mechanism, and where it needs a design decision or confirmation against current Ceph documentation.

Which Ceph deployment path fits a vSAN estate

vSAN hosts compute and storage in the same cluster, so the choice of Ceph layout decides how failures, upgrades and capacity growth affect your VMs. The three paths below differ mainly in who owns the storage failure domain and which management plane you operate. Confirm each option against your own hardware, network and team skills before you commit.

Sizing nodes, networks and memory for Ceph

This sequence turns a vSAN-style hyper-converged idea into a Ceph cluster sizing that a team can defend in a design review and test before buying hardware. Each step fixes one decision, and the output is a written bill of materials validated by a benchmark on representative hardware.

1. Fix the node count and hardware baseline

   The architecture owner sets the node count first, because every later number depends on it. Proxmox VE recommends at least three servers for a hyper-converged Ceph cluster, and preferably identical ones, so that CPU, memory, drives and NICs behave the same under rebalancing and recovery. Record the planned node count, the CPU model, the memory per node and the drive models in one table. The step is done when every node in the design matches that table and the team has agreed that a single node failure leaves enough capacity to run the workloads in the design.

2. Design a dedicated 10 Gbps Ceph network

   The network engineer allocates a separate network for Ceph replication and recovery traffic, sized at 10 Gbps or more and used only for Ceph. Keep client and management traffic off it so that a rebuild after a failed drive does not slow virtual machines. Bond the links across two switches so that a switch failure does not isolate a node. Confirm with the switch vendor that the chosen switches support the bonding mode and jumbo frames you plan to use. The output is a addressing and cabling diagram that shows which ports go to which switch and which subnet carries Ceph traffic.

3. Reserve CPU cores for each Ceph service

   Count the Ceph services that will run on each node, including OSDs, monitors, managers and metadata servers if CephFS is used. Proxmox VE recommends at least one CPU core per Ceph service, and that reservation must be added on top of the cores needed by the virtual machines. The administrator should write the core count per service into the sizing sheet and confirm that the remaining cores still meet the workload plan. The step is complete when each node's core budget shows both Ceph and guest allocations and the total fits the hardware.

4. Size memory per OSD for peak load

   Proxmox VE recommends at least 8 GiB of memory per OSD, and the Ceph hardware recommendations advise sizing for peak use rather than calm periods. Multiply the OSD count per node by 8 GiB as a floor, then add memory for the virtual machines, the operating system and any monitors or managers. Recovery after a node failure creates the peak, so the design should be checked against a scenario where one node's OSDs rebuild while the remaining nodes carry its guests. The output is a memory figure per node that the team can explain to the hardware vendor.

5. Assign one drive per OSD and plan WAL and DB

   The storage designer assigns a dedicated physical drive to each OSD and avoids sharing one device between OSDs. For HDD-based OSDs, the Ceph hardware recommendations suggest moving the WAL and DB onto shared enterprise-class SSDs, so the design lists which SSD serves which HDD group and how much capacity it leaves for metadata. Choose enterprise-class SSDs for that metadata role, and confirm their endurance and power-loss protection with the vendor. The step is done when a drive map lists every OSD, its data device and its WAL and DB device, with no device serving two roles it cannot sustain.

6. Exclude RAID controllers from the storage path

   The platform engineer checks each server's storage controller and configures the disks in pass-through or HBA mode for Ceph. Proxmox VE advises against RAID controllers because Ceph already handles redundancy across hosts, and a RAID layer under an OSD hides drive faults from Ceph and can add a second layer of recovery work. Confirm in the hardware order that the controller is an HBA or can be placed in that mode, and record the firmware version. The check is complete when every Ceph data drive appears to the operating system as an individual device.

7. Set pool redundancy and run a pre-purchase benchmark

   The Proxmox VE wiki advises a Ceph pool min_size of at least 2 to prevent data loss, so the design records the replication or erasure-coding profile and the min_size for every pool. The Ceph hardware recommendations say to benchmark before buying because no two clusters are alike. The team should run a test on hardware that matches the design and measure IOPS, latency at the expected queue depth, throughput during a simulated OSD failure, and recovery time under load, using workloads that resemble the virtual machines. The output is a benchmark report that either confirms the sizing or sends the team back to step one or four.

8. Document the sizing decision for approval

   The architecture owner compiles the node count, network design, core and memory budgets, drive map, controller configuration and pool settings into one sizing record. The record should state the assumptions behind each number, the failure scenarios tested and the measured results from the benchmark. Ask the hardware and support vendors to confirm the configuration in writing before purchase. The step is done when an approver who was not part of the design can trace every sizing decision back to a rule, a test or a named assumption.

Data protection settings that prevent Ceph data loss

What performance can a team expect from Ceph compared with vSAN

Moving VMs off vSAN-backed disks

The sequence builds and proves the Ceph target first, then moves workloads in validated waves, so each VM reaches Proxmox VE storage with a tested rollback path before vSAN is retired. Teams end with evidence of recovery, not just a cluster that boots.

1. Build and prove the Ceph target

   Your infrastructure team deploys the hyper-converged Ceph cluster in Proxmox VE on at least three servers, preferably identical, using the web wizard or the pveceph CLI. Confirm that the dedicated Ceph network runs at 10 Gbps or faster, that each OSD has a dedicated drive, and that no RAID controller sits between the disks and Ceph. The step closes when the cluster reports healthy and a test pool accepts writes at the pool min_size of 2 that Proxmox recommends.

2. Benchmark against the vSAN workload profile

   Before any VM moves, measure the Ceph pools with a load that resembles your production I/O mix, including mixed read and write patterns and the peak periods your monitoring shows. Ceph guidance says to benchmark before buying and to size memory for peak use, so compare results with the vSAN figures you already collect. The step closes with a signed-off benchmark report that states whether Ceph meets the latency and throughput targets for the first wave, and with a list of any shortfalls to fix first.

3. Inventory VMs and classify their disks

   Your virtualization team lists every VM on vSAN datastores with its disks, guest OS, VMware Tools status, snapshots, encryption settings and dependencies such as backup jobs. Mark VMs that cannot use the Proxmox import wizard, since the wizard cannot import vSAN-backed disks, and assign each one to an export path: OVF import, qm disk import for VMDK files, or Clonezilla. The step closes with a migration register that names a path and a wave for every VM.

4. Remove snapshots and copy disks in waves

   Consolidate or delete snapshots on each VM before import, because Proxmox documents that VMs with snapshots import more slowly. Export disks from vSAN through the chosen path and import them into Ceph-backed storage on Proxmox VE, starting with low-risk test workloads and then moving production groups by dependency. The step closes when each VM boots on Proxmox VE with its disks attached to Ceph and its network mapped, and the wave log records the start and end time of each copy.

5. Validate each wave before cutover

   Application owners and the operations team check each migrated VM against an agreed test list: boot, service health, application login, data integrity checks on key records, backup job success and monitoring alerts. Compare performance against the benchmark baseline so that a slow VM is caught before it serves users. The step closes with a signed acceptance record per wave, and a wave that fails any check stays on vSAN until the cause is fixed.

6. Keep rollback paths until acceptance

   Keep each source VM on vSAN in a powered-off or read-only state, with its original disks untouched, until the wave has run through its agreed acceptance period. Confirm that the backup set taken before the move can restore the VM to its vSAN state if needed, and document who can trigger a rollback and how. The step closes when the rollback runbook has been tested on at least one VM from each wave and the team signs that the path works.

7. Test recovery before decommissioning vSAN

   Run a failover test on the Proxmox VE cluster, including a node failure with HA, a Ceph OSD failure and a restore from backup into a test network, and record how long each recovery took against your recovery objectives. Confirm that the Proxmox high availability setup meets its stated requirements for quorum, shared storage and watchdog fencing. The step closes with a written recovery report that the business owners accept, and only after that report does the team plan the vSAN decommission.

Running Ceph alongside the remaining vSphere estate

How much effort, time and skill does a vSAN to Ceph move need

What a fixed-scope vSAN replacement covers