Open-source alternative to Storage Spaces Direct

Which Storage Spaces Direct capabilities Ceph covers and where it differs

This table maps the main Storage Spaces Direct capabilities to their Ceph equivalents and marks where the match is partial or missing. Read each row as a question to answer in your own environment, since gaps in Windows-integrated management and SMB access shape most migration work.

Ceph, Proxmox VE with Ceph, and Rook: which option fits

How to size nodes and networks for Ceph versus Storage Spaces Direct

Where Ceph changes operations, skills and risk

Replacing Storage Spaces Direct with Ceph moves storage work from Windows administration to Linux and Ceph operations. The cards below cover the skills, quorum and network needs, release lifecycle, recovery tooling, access controls and in-cluster traffic protection that change with that move. Each one is a decision or check to make before the cluster goes into production.

Moving VM disks off Cluster Shared Volumes to Ceph

This sequence moves each workload's disks from Cluster Shared Volumes to Ceph storage in Proxmox VE in an order that keeps backups verified and rollback possible until Storage Spaces Direct is retired. Each step ends with a check that the next one depends on.

1. Inventory clusters, volumes and workloads

   The Hyper-V administrator lists every clustered role, its owning node, every Cluster Shared Volume it uses, and the VM disk paths, checkpoints and dependencies between VMs, such as domain controllers, databases and application tiers. Export the inventory to CSV so the list can be reviewed by the application owners before any move is scheduled. The step is done when every VM has a named owner, a target order and a confirmed backup, and the application owners have signed off the list in writing.

2. Build and benchmark the Ceph cluster

   The infrastructure team builds the Ceph cluster on hardware sized against the Ceph hardware recommendations, with a dedicated drive per OSD, enterprise-class SSDs for metadata, bonded network links across two switches, and memory sized for peak use. Benchmark the cluster under a load that resembles the production workload before any VM disk is copied, since the project advises benchmarking because no two clusters are alike. The step is done when the benchmark results are recorded against the agreed targets and a failed-disk and failed-node test has been run successfully.

3. Add Ceph as Proxmox storage

   Proxmox VE nodes are joined into a cluster and the Ceph RBD pool is registered as shared storage for guest disks, so every node can reach the same volumes. Confirm that the cluster has at least three nodes for reliable quorum and that high availability fencing is configured before any clustered workload depends on it. The step is done when a test disk can be created, started on a second node and removed cleanly, with the pool's health reported as normal.

4. Export and convert VHDX disks

   Export each VM with the Hyper-V export process described in the Hyper-V export guide, merge checkpoints where the migration guidance calls for it, and convert VHDX files into a format the Proxmox import tooling accepts. Check free space on the staging volume before conversion, because conversion needs room for both the source and the output. The step is done when each disk has a checksum recorded at export and a successful conversion log.

5. Import disks with qm disk import

   Create an empty VM shell on Proxmox VE with matching firmware, machine type and CPU settings, then attach each converted disk to Ceph storage with qm disk import on the Proxmox node. Follow the Hyper-V migration guide for Generation 2 and UEFI settings, and compare the imported disk size and boot order with the Hyper-V inventory. The step is done when every disk appears on the target storage with the expected size and the VM configuration matches the inventory row.

6. Switch Windows guests to VirtIO drivers

   Install the VirtIO storage and network drivers in each Windows guest while it still boots from the original controller, then change the disk and network adapter to VirtIO devices in the Proxmox configuration. Windows guests that cannot load the storage driver will fail to boot, so the driver step must finish before the controller is changed. The step is done when each guest boots from Ceph-backed VirtIO disks and reports the expected driver versions.

7. Test boot, networking and application health

   Start each migrated VM in an isolated VLAN or test network, then verify boot, time sync, domain membership where applicable, VLAN tagging, DNS and the application's own health checks. Compare results against the inventory and record any differences, such as changed MAC addresses that affect licensing or firewall rules. The step is done when the application owner confirms the test results in writing and no open defects block the cutover.

8. Cut over clustered workloads in order

   Move workloads in the dependency order from the inventory, starting with infrastructure services such as DNS and directory roles, then databases, then application tiers. Take a fresh backup and confirm it can be restored before each cutover, and keep the Hyper-V source VM in a powered-off state until the rollback window closes. The step is done when each workload has a documented cutover time, a verified backup and an owner's acceptance note.

9. Decommission Storage Spaces Direct after verified backups

   Retire the Cluster Shared Volumes only after every workload runs on Ceph and the backup platform has restored a sample of VMs from the new environment. Remove the Hyper-V cluster roles, wipe the S2D disks under a documented procedure and update the asset register and runbooks. The step is done when the backup restore tests have passed, the S2D pool is removed from the cluster, and the change record is signed by the infrastructure owner.

Questions buyers ask before replacing Storage Spaces Direct

Keeping Windows workloads running while storage moves

How to run a Ceph pilot before committing hardware

A pilot turns Ceph sizing assumptions into measured results on your own workloads, so the hardware purchase rests on tested behavior for performance, failure handling and recovery. It ends with a written go or no-go decision that the infrastructure, security and operations owners have all signed.

1. Define workloads and performance targets

   Start by listing the Hyper-V workloads that would move to Ceph, such as SQL Server, file services, domain controllers and general application servers, and record how each one uses storage: read and write mix, block sizes, peak hours and latency sensitivity. The infrastructure lead and the application owners agree on targets in writing, including acceptable latency during peak use and the data protection level each workload needs. Done when every workload has a named owner and a measurable target that the pilot can test.

2. Select and document the test cluster

   Choose a small set of servers that match the hardware you are considering, with a dedicated drive per OSD, enterprise-class SSDs for metadata and bonded network links across two switches, as the Ceph hardware recommendations describe. Record the CPU, memory, drive models, NIC and switch configuration, and the Ceph release, such as the Squid or Tentacle branch that is actively maintained at the time. Confirm with your hardware vendor and Ceph support path that the chosen release and components are supported together. Done when the bill of materials and the version baseline are documented and reviewed.

3. Deploy the pilot cluster with cephadm

   Use cephadm to bootstrap the pilot cluster, adding hosts and services in the same way the production cluster will be built, so the runbooks you write are the ones you will use later. The platform engineer records every deviation from the planned design, such as network or drive substitutions, because each one changes the results. Done when the cluster reports healthy, all monitors and managers are running, and the build steps are captured as repeatable procedures.

4. Benchmark against the workload targets

   Run benchmarks that reflect the workload profiles from the first step rather than generic synthetic numbers, and repeat each test enough times to see variation. Memory should be measured under peak conditions, not idle ones, because the Ceph hardware recommendations advise sizing for peak use. Compare results with the targets and note where the cluster falls short, which may point to a different drive, network or memory choice. Done when a signed results sheet shows each workload against its target, with the test conditions recorded.

5. Test failure and recovery drills

   Simulate realistic faults in a controlled window: take a host offline, fail a drive, partition a network link and restore it, and watch how Ceph rebalances and how long client I/O is affected. Include a planned maintenance drain so the operations team learns the procedure before it is needed. Measure recovery behavior against the targets, and confirm that the application owners see the outcome they agreed to accept. Done when each drill has a logged result, a timeline and a follow-up action for anything outside the agreed tolerance.

6. Validate security and access controls

   Confirm that the security configuration matches the requirements: enable the messenger v2 secure mode so post-authentication traffic is encrypted, restrict Dashboard access, and check how single sign-on would integrate with your identity provider. Review administrative accounts and who can change pools and cluster settings. The security lead signs off on the findings, and any gap becomes a documented risk with an owner. Done when the security review is recorded and no open item blocks the production design.

7. Set go or no-go criteria and decide

   Before the pilot begins, agree on the criteria that will decide the outcome, covering benchmark results, drill outcomes, operational effort and the team's readiness to run Ceph. Review the evidence against those criteria with the CIO or infrastructure head and record the decision. A no-go is a valid result and should name what would change the answer, such as different hardware, a different Ceph release or more operator training. Done when the signed decision record exists and, if the answer is go, the production purchase is scoped from the tested configuration.

Running Ceph alongside the rest of the suite

Ceph does not run alone in a virtualization estate. Identity, backup, management and monitoring each need a decision before cutover, and each one can quietly reintroduce a dependency on the Windows stack you are leaving. The cards below name the integration points to settle and what to confirm with each vendor or in your own environment.

How DeployOpen scopes a storage replacement