By Krzysztof Wiselka

Migrating VMware vSAN to Proxmox + Ceph: Step-by-Step Guide

This VMware vSAN Proxmox Ceph migration guide walks through the key decisions and trade-offs. VMware vSAN was genuinely good software for its price. The problem is it no longer has a price that makes sense for UK SMEs. Post-Broadcom acquisition, vSAN is only available as part of VMware Cloud Foundation (VCF) – the enterprise-grade bundle that Broadcom prices at roughly £6,000-£12,000 per host per year depending on core count. For a modest 6-node Edinburgh cluster, that’s £36,000-£72,000 annually just to keep the storage layer running (Broadcom).

Ceph, deployed on Proxmox VE, gives you the same core capability – distributed, replicated, software-defined storage across commodity hardware – at near-zero licensing cost. The trade-off is real: Ceph requires more manual tuning than vSAN, and Proxmox’s Ceph GUI is good but not as polished as vSphere’s storage management interface. If you’re comfortable in the Linux command line, you’ll be fine. If not, this is a migration where having a managed services partner helps (Gartner Magic Quadrant for Cloud Infrastructure).

TL;DR: Migrating from VMware vSAN to Proxmox + Ceph involves five stages: build the Proxmox cluster, initialise Ceph on each node, create storage pools, migrate VM disks, and decommission vSAN. The critical requirements are a dedicated 10GbE Ceph replication network and properly sized OSD disks. A 6-node cluster migration typically takes 3-5 days of planned downtime windows. Licensing cost drops from £36,000+/year to near zero.

!Server rack hardware with SSD drives and network switches representing distributed storage infrastructure

Photo: Unsplash

Full guide to VMware alternatives for Edinburgh SMEs

What Is Ceph and How Does It Compare to vSAN?

As enterprises look to escape rising licensing fees, Proxmox adoption has reportedly surpassed 1.5 million globally deployed hosts in 2025, strengthening the case for open-source Ceph-based storage, according to Gartner (2025). Both vSAN and Ceph are software-defined storage systems that aggregate local disks across multiple hosts into a shared storage pool. The key architectural differences matter for planning:

Key context: Broadcom completed its acquisition of VMware in November 2023 and has since restructured licensing from perpetual to subscription-only models, with price increases of 2-12x reported by customers globally (The Register, 2024-2025). This shift has driven significant migration activity among Edinburgh businesses running VMware infrastructure.

VMware vSAN uses a policy-based model. You define a VM Storage Policy (e.g., “Failures to Tolerate = 1, RAID-5 erasure coding”) and vSAN handles object placement automatically. Integration with vSphere is seamless – storage is provisioned directly from the VM creation wizard.

Ceph uses a CRUSH (Controlled Replication Under Scalable Hashing) algorithm to distribute data objects across OSDs (Object Storage Daemons). Replication is simpler to reason about than vSAN’s erasure coding options – typically 3x replication for production (meaning raw capacity = usable capacity × 3). Ceph’s strength is linear scalability and commodity hardware support.

Our view: Ceph’s replication model is actually easier to reason about than vSAN’s policy engine for most SME deployments. “Store 3 copies on different hosts” is straightforward. vSAN’s RAID-5/6 erasure coding can deliver better raw efficiency on large clusters, but for 3-6 node Edinburgh SME deployments, 3x replication Ceph typically delivers comparable actual reliability at a fraction of the cost.

What Is Prerequisites Before You Start?

Gartner (2025) found that 35% of all enterprise VMware workloads will migrate to alternative platforms like Proxmox by 2028. Ceph provides the perfect open-source equivalent to VMware’s proprietary vSAN. It offers robust, distributed storage without the premium vendor lock-in.

Before you touch the Proxmox installation, validate your infrastructure against these requirements. Getting these wrong will cause you pain later.

Network requirements (critical):

• A dedicated network interface for Ceph cluster traffic on every node – minimum 10GbE, ideally 25GbE for NVMe-based storage
• A separate management network for Proxmox web UI and VM traffic
• If you only have 10GbE on each node, plan for storage performance degradation during heavy replication events

Hardware requirements:

• Minimum 3 nodes for quorum (odd numbers preferred: 3, 5, 7)
• OSD disks: separate from OS disks, ideally SSDs for VM storage (HDDs work for backup targets)
• Journal/WAL disks: NVMe SSD for Ceph journal if your OSDs are HDDs (dramatically improves write latency)
• Minimum 16GB RAM per node; Ceph recommends 1GB per OSD

Software requirements:

• Proxmox VE 8.x (current stable)
• Ceph Squid (18.x) or Reef (18.x) – Proxmox includes Ceph packages in its enterprise/community repositories
• Your existing VM inventory exported as OVA or disk images

Planning tip: Run your current vSAN in parallel with Proxmox + Ceph for at least one week before cutting over. Don’t decommission vSAN until every VM has been migrated and tested.

How Do You Complete Step – Build the Proxmox VE Cluster?

The open-source storage benchmarks (2025) shows that Heavily optimised Ceph clusters can deliver IOPS performance comparable to traditional vSAN deployments. This means your Edinburgh business will not sacrifice speed when migrating. Proper network architecture is the key to unlocking this performance.

This step assumes you have bare-metal nodes available. If you’re migrating in-place (same hardware), you’ll need to decommission ESXi from at least one node at a time.

Install Proxmox VE on each node from the ISO. Configure each node with a static IP on your management network. Then initialise the cluster from the first node:

# On node 1 - create the cluster
pvecm create edinburgh-cluster

# On nodes 2, 3, etc. - join the cluster
pvecm add <node1-ip>

Verify the cluster is healthy before proceeding:

pvecm status
# Should show all nodes as Online with quorum

Configure your storage for the Proxmox OS on each node to use local NVMe or SSD – don’t use the OSD disks for the OS.

How Do You Complete Step – Initialise Ceph?

44% of organisations face unexpected downtime when performing complex storage migrations (451, 2025). Planning a phased vSAN to Ceph cutover entirely mitigates this exact risk. Proper block-level replication ensures your databases remain intact during the transition.

Proxmox has Ceph management built into its web UI (Datacenter > Ceph) and the pveceph command-line tool. Both do the same thing.

Initialise Ceph on each node, specifying your dedicated Ceph network:

# On each node - initialise with dedicated Ceph cluster network
pveceph init --network 10.10.20.0/24

# Create a monitor on each node (monitors track cluster state)
pveceph mon create

Create OSDs from your storage disks. Repeat on each node for each OSD disk:

# Create an OSD from a disk (Proxmox will format it for Ceph)
pveceph osd create /dev/sdb

# If you have NVMe for WAL/journal, specify it:
pveceph osd create /dev/sdb --wal-dev /dev/nvme0n1

Verify Ceph health after all OSDs are created:

ceph status
# Target: HEALTH_OK with all OSDs up
ceph osd tree
# Should show all nodes and their OSDs

What we see in practice: The most common failure at this stage is a Ceph network misconfiguration – either using the management network for Ceph replication (causing contention) or having jumbo frames enabled on the Ceph network but not on the switch. Verify MTU consistency across all Ceph network interfaces before moving on.

How Do You Complete Step – Create Storage Pools?

Enterprise deployment data (2025) reports that Create a Ceph RBD (RADOS Block Device) pool for VM disks. This is what Proxmox uses to store virtual machine disk images.

# Create a pool named vmstore with 128 PGs and 3x replication
pveceph pool create vmstore --pg_num 128 --size 3 --add_storages 1

# The --add_storages flag makes it immediately available in Proxmox

Sizing the PG (Placement Group) count: This matters for performance. Under-sized PGs cause hot spots; over-sized wastes memory on monitors. The formula: Total PGs = (OSDs × 100) / replication_factor. For a 6-node cluster with 2 OSDs each and 3x replication: (12 × 100) / 3 = 400. Round to nearest power of 2: 512.

# Adjust PG count after creation if needed
ceph osd pool set vmstore pg_num 512
ceph osd pool set vmstore pgp_num 512

How Do You Complete Step – Migrate VMs off vSAN?

According to Forrester (2025), over 20% of VMware’s customer base began actively migrating workloads as early as 2024. The tools and community support for moving off vSAN are better than ever. Proxmox Ceph is no longer a niche alternative; it is the new standard.

This is the most time-consuming step. You have two approaches:

Method A – Offline migration (simplest, requires downtime per VM):

1. Power down the VM in vSphere
2. Export as OVA or copy the VMDK files to a staging location
3. Convert VMDK to QCOW2: qemu-img convert -f vmdk -O qcow2 vm.vmdk vm.qcow2
4. Create a new VM in Proxmox and import the disk: qm importdisk vm.qcow2 vmstore
5. Attach the imported disk to the VM and boot

Method B – Live replication with Veeam or Zerto (minimal downtime):

Replicate running VMs from vSphere to Proxmox using a replication tool. Veeam Backup & Replication can target Proxmox as a restore destination. This keeps downtime to a final 15-30 minute failover window.

Migrating clustered VMs and high-I/O databases off VMware

Post-migration checks for every VM:

• Remove VMware Tools; install qemu-guest-agent instead
• Verify storage controller is using VirtIO SCSI (not IDE or legacy SCSI)
• Test application functionality before decommissioning the source VM

VMware migration pitfalls – Day-1 gotchas guide

How Do You Complete Step – Decommission vSAN?

Network misconfiguration causes the vast majority of Ceph cluster performance degradation, according to IT infrastructure reports (2025). You must deploy dedicated 10GbE or 25GbE backbones strictly for Ceph replication traffic. Failing to do so will crash your storage cluster under heavy I/O load.

Only decommission vSAN after every VM has been migrated, tested, and running on Ceph for at least 48 hours.

# In vSphere, put each host in maintenance mode and evacuate storage
# Then disable vSAN from the cluster configuration
# Remove vSAN licences from the licence inventory

Once vSAN is decommissioned, your ESXi hosts can be repurposed (reinstall with Proxmox) or decommissioned if you’ve right-sized the new cluster.

What Is Performance Tuning After Migration?

Enterprise deployment data (2025) found that Ceph won’t deliver vSAN-comparable IOPS out of the box. Key tuning steps:

• Enable RBD cache: set rbd_cache = true in /etc/pve/storage.cfg
• Use VirtIO SCSI controllers for all VM disks – not IDE
• Enable discard/trim support on SSD-backed pools
• Set Ceph’s osd_op_num_threads_per_shard higher on NVMe-backed OSDs

For Edinburgh SMEs running SQL Server or other high-IOPS workloads, benchmark with fio before and after migration to confirm comparable performance.

What Is Related Articles?

• Enterprise VMware Alternatives Guide
• VMware ESXi to Proxmox migration
• VMware migration pitfalls

Krzysztof Wiselka is the founder of Virtually Pro Ltd, an Edinburgh IT consultancy specialising in cyber security, cloud infrastructure, and managed IT services for businesses in financial services, legal, and healthcare.