XCP-ng vs Proxmox: Picking the Hypervisor After VMware

A team leaving VMware is not buying a feature list; it is choosing which control plane it will operate for the next ten years, which storage ceilings it will hit, and which recovery procedure someone will run at three in the morning. This article compares XCP-ng 8.3 and Proxmox VE 9 on those operator axes, using each project's own documentation as of 26 October 2026. For the deep dive on Proxmox alone — corosync, Ceph versus ZFS replication, PBS retention — read Stribog's Proxmox VE production guide.

Two hypervisors, two management planes

XCP-ng: a pool coordinator and an orchestrator VM

XCP-ng runs the Xen hypervisor with a privileged control domain, dom0, on each host. Hosts join a resource pool of up to 64 hosts managed as a single entity. One host is the pool coordinator (the role formerly called pool master): it exposes the XAPI endpoint for the whole pool, holds the pool database and forwards operations to the other members, each of which keeps a replicated copy of that database.

The coordinator is not the console. The officially supported client is Xen Orchestra, developed by Vates, the same team behind XCP-ng. It is more than a client: because it runs 24/7 as a daemon, it is what provides ACLs, VM load balancing, the SDN controller, backup, incremental backup, disaster recovery and continuous replication. It comes in two flavours. XOA is a turnkey appliance tested and bundled with commercial support. The other is a manual install from GitHub, which Vates' own docs say has no professional support and no QA beyond what the community reports; for production they point you to XOA.

So the XCP-ng management plane has two failure modes. If Xen Orchestra is down, the reasonable inference from those docs is that the jobs it owns — scheduled backups, replication runs, SDN changes — stop until it returns, while the hosts carry on serving the VMs already running. For that window there is XO Lite, a work-in-progress web client served directly from an XCP-ng host over HTTPS, meant for basic management when full Xen Orchestra is not installed or temporarily unavailable. Its feature set is currently limited. The xe CLI on any host remains the floor.

If the coordinator is lost, what happens depends on whether pool HA is enabled. With HA, another host takes over the coordinator role automatically. Without HA, nothing promotes itself. A member accepts promotion only after it has entered emergency mode — it can no longer reach the coordinator after some number of retries — and then an operator runs two commands on the survivor:

# On a surviving member that is already in emergency mode:
# make this host the pool coordinator.
xe pool-emergency-transition-to-master

# Tell the remaining members to point at the new coordinator.
xe pool-recover-slaves

One warning belongs in the runbook beside the first command: the XCP-ng CLI reference notes that if the host password has been modified since the host joined the pool, pool-emergency-transition-to-master can cause that host's password to reset. Rehearse it before you need it.

Proxmox VE: every node is the management plane

Proxmox VE runs KVM and QEMU on Debian, and its documentation states the design in one line: every node in a cluster can perform all management tasks, and there is no central management server. Cluster configuration lives in pmxcfs, which corosync replicates in real time to every node, with a 128 MiB maximum size. The web GUI is served by every node. There is no management VM to lose.

The price is quorum. Proxmox clusters are multi-master and operate on a majority of votes, one per node, and Proxmox says at least three votes are needed for a stable cluster; two-node clusters can borrow an extra vote from a QDevice. The cluster stack needs latencies under 5 milliseconds between nodes, and corosync should ideally run on its own physically separate network; it should not share a network with storage except as a potential low-priority fallback in a redundant configuration. Proxmox documents no explicit node limit and cites reports, as of 2021, of production clusters with over 50 nodes on high-end hardware — set that beside XCP-ng's documented cap of 64 hosts per pool.

Above the cluster sits the optional Proxmox Datacenter Manager. Version 1.0, its first stable release, shipped on 4 December 2025; 1.1, released 28 May 2026 on Debian Trixie 13.5, can migrate a VM or container between separate Proxmox VE clusters, which it calls remotes. It is a multi-cluster view, not a required control plane: a cluster without it is fully manageable.

Click to zoom

Storage: SRs and VDIs versus storage plugins

XCP-ng presents storage as storage repositories (SRs) that hold virtual disk images (VDIs). The current stack, SMAPIv1, uses VHD as its default disk format, with a hard ceiling of 2040 GiB per disk. Since 5 May 2026, XCP-ng 8.3 also supports QCOW2 on the same stack, with disks up to 16,381 GiB on most SR types, except XOSTOR and SMB. That support is under six months old at the time of writing; treat it as new. A RAW disk sidesteps the VHD limit, but you lose live storage migration and snapshots on it.

The XCP-ng storage support table is worth reading row by row before you map a SAN onto it:

• NFS — shared, thin-provisioned, supported.
• iSCSI, HBA and Fibre Channel — shared and supported, but thick-provisioned.
• Local LVM — supported, neither thin nor shared.
• XOSTOR — shared, thin, supported: the hyperconverged option, built on LINSTOR and officially supported on XCP-ng 8.3 since 16 June 2025, "as long as it is up to date" (the note does not say which component).
• ZFS, CephFS and CephRBD — available, but marked "No. Provided as-is" rather than supported.

The thick rows matter more than they look. XCP-ng's docs warn that thick provisioning is relatively costly when you take snapshots, and backups take snapshots; if thin storage such as local EXT or NFS is an option, the docs say you will save a lot of space. An existing iSCSI or FC array therefore works, but it is the expensive way to run a backup-heavy estate on XCP-ng.

Proxmox VE uses storage plugins instead: local ZFS with snapshots, NFS and CIFS, CephFS, LVM, and Ceph RBD, block storage with full snapshot and clone support. Proxmox generally recommends Ceph for shared storage. For teams keeping a SAN, its migration guide lists one big iSCSI or FC LUN with shared LVM-thick, which has cluster-wide locking when marked shared. Snapshots are not possible there by default; enabling "Allow Snapshots as Volume-Chain" adds them by layering qcow2 volumes as a backing chain. That feature arrived as a technology preview in Proxmox VE 9.0 and the storage guide still labels it one. The LVM plugin itself is not a preview.

On a classic block SAN, both platforms give you thick, shared volumes, and both make snapshots the uncomfortable part — costly on XCP-ng, preview-grade on Proxmox. If you are building hyperconverged, the choice is XOSTOR (LINSTOR) against Ceph. Stribog's Kubernetes storage comparison covers what operating Ceph actually asks of a team.

Networking: Open vSwitch by default, Linux bridge by default

XCP-ng uses Open vSwitch as its networking core. On top of it, Xen Orchestra's SDN controller builds private networks over GRE or VXLAN tunnels that every host in a pool, and even hosts in different pools, can reach. The newer OpenFlow-rules implementation is still marked BETA with an explicit warning not to use it in production. Note the dependency: the SDN controller is part of Xen Orchestra, the same always-on VM discussed above. XCP-ng 8.3 also asks you to choose dom0's addressing at install — IPv4 only, IPv6 only, or dual stack, which is still experimental — and the mode cannot be changed afterwards.

Proxmox VE goes the other way. Its virtual switches, vmbr0 and onwards, are plain Linux bridges that handle VLANs; cluster-wide VLANs can be defined through SDN VLAN zones. Proxmox says Open vSwitch can be used but is rarely necessary. For a team whose network engineers know Linux bridging, that is less to learn; for a team already fluent in OVS, XCP-ng's default is the familiar one.

Live migration and HA: who decides a host is dead

On XCP-ng, HA is pool-level only — it cannot span pools — and the docs recommend at least three hosts; two hosts risk being fenced if the link between them drops. It needs shared storage with a heartbeat SR of at least 4 GiB on iSCSI, NFS, XOSTOR or Fibre Channel; SMB and CHAP-authenticated iSCSI cannot hold the heartbeat. With HA on, the coordinator detects a lost host, and if the coordinator itself is lost another host takes over its role. The docs' worst case is a host that loses network but keeps storage: it hard-powers-off and restarts, a procedure the docs call fencing.

#!/usr/bin/env bash
set -euo pipefail

# Show the pool's SRs: type and shared flag decide heartbeat eligibility
# (iSCSI, NFS, XOSTOR or FC; not SMB, not CHAP iSCSI; at least 4 GiB).
xe sr-list params=uuid,name-label,type,shared

# Pick the SR prepared for the heartbeat, then enable pool HA against it.
SR_UUID=$(xe sr-list name-label=ha-heartbeat params=uuid --minimal)
xe pool-ha-enable heartbeat-sr-uuids="$SR_UUID"

Proxmox VE decides differently. A node that leaves quorum cannot reset its watchdog, but it self-fences only if it has active HA services, or if its LRM or CRM process is not scheduled or is killed, it reboots once the watchdog times out after 60 seconds. A node with an active CRM but an idle LRM does not self-fence on quorum loss. A runbook that says every quorum loss resets a node will mislead its reader mid-incident.

Live migration has its own preconditions. Both hosts must be in the same Proxmox VE cluster, the target must run the same or newer Proxmox VE package versions, the CPUs must be from the same vendor with similar capabilities, and passed-through PCI or USB devices block it. Local disks do not: they can be sent to the target during the move. On a same-cluster move, --targetstorage remaps only non-shared disks; disks on shared storage (Ceph, NFS, shared LVM) stay put and are not copied. Shared storages are remapped only on a remote migration.

#!/usr/bin/env bash
set -euo pipefail

# Confirm the cluster is quorate before moving anything.
pvecm status

# Live-migrate VM 101 to node pve2, copying its local disks
# onto the target's local-zfs storage while it keeps running.
# --targetstorage remaps non-shared disks only; disks on
# storage marked shared stay put and are NOT copied.
# Source and target need the same CPU vendor (no Intel -> AMD)
# with similar capabilities, and the same architecture.
qm migrate 101 pve2 --online 1 --with-local-disks 1 --targetstorage local-zfs

The architectural contrast is the useful part. XCP-ng's HA leans on a shared heartbeat SR as well as the network, and its documented worst case — network lost, storage kept — ends with the host fencing itself by hard power-off and restart. Proxmox's arbiter is corosync quorum on the network: lose the majority with HA active and the watchdog fences. Your existing failure history — flaky storage fabric or flaky network — is a reasonable tiebreaker.

Backup: built into the console or a separate product

On XCP-ng, backup is a Xen Orchestra feature. Incremental backups start with a full key backup; each later run compares the disks to the previous snapshot and transfers only the changed blocks as a delta, and a restore reads the whole chain and rebuilds the VM automatically. Incremental replication, formerly Continuous Replication, sends a VM on a configurable interval of minutes or hours (the docs give an RPO from 10 minutes to 24 hours or more) to any SR, including a distant XCP-ng host, again shipping only changed blocks after the first full transfer. Metadata backups capture the pool's XAPI database and Xen Orchestra's own configuration — back up both. Neither brings the appliance VM back; Vates treats keeping the XOA itself recoverable as the other half of the job.

Proxmox VE backs up through the archive-based vzdump tool or Proxmox Backup Server, a separate AGPLv3 product. PBS deduplicates independently of the filesystem, sends only incremental changes for running VMs, supports live-restore, and can encrypt on the client side with AES-256 GCM, before data leaves the hypervisor. Whichever you run, pair it with an off-site copy you cannot delete from the primary; Stribog's immutable backups guide covers that tier.

Getting off VMware: V2V warm migration versus the ESXi import wizard

Xen Orchestra's V2V is designed as a warm migration: it exports an initial snapshot of the VMware VM while the VM keeps running, then shuts the VM down and exports only the blocks changed since the snapshot. It needs no direct access to VMware storage, only HTTP access to the ESXi API. But that warm path is documented for VMFS 5 and NFS datastores only, and even on VMFS 5 it is only reported to work in most cases, with a stopped-VM migration as the fallback. On VMFS 6 the VM must be shut down, and on vSAN powered off. VMFS 6 is the default format when creating a datastore on hosts that support it, and the vSphere 8 wizard still lists VMFS 5, so check each datastore before assuming a warm copy. Other hard constraints: raw disks are not supported, current Xen Orchestra does not support ESXi 6.x hosts, and the VM must have at least one snapshot with an account allowed to stop it. Since Xen Orchestra 5.112, VMware disks larger than 2040 GiB arrive as QCOW2, which needs XCP-ng 8.3 and a QCOW2-capable SR — not XOSTOR, not SMB.

The Proxmox VE ESXi import was tested against ESXi 6.5 through 8.0. It cannot import disks backed by vSAN or encrypted disks, and VMs with snapshots import significantly more slowly. Live-import starts the target VM during the import to cut downtime — the source VM must still be switched off first, VMware tools should be uninstalled, and vTPM state cannot be migrated. One sharp edge: if the import fails, every write since it started is lost.

Two of those constraints decide platforms on their own. An estate still on ESXi 6.x cannot use XO V2V without upgrading first; an estate on vSAN cannot use the Proxmox importer directly. And neither path keeps a VMFS 6 or vSAN guest running through the whole copy. Inventory both before you shortlist.

Audit, lifecycle and the exit ramp

XCP-ng 8.3 was released on 7 October 2024, became LTS on 16 June 2025 and is supported until 30 November 2028. It is partly based on XenServer 8, runs Xen 4.17.5 plus patches, and its dom0 is based on CentOS 7 plus security fixes backported by XCP-ng's Security Team, on Linux 4.19 plus patches. An auditor will notice the CentOS 7 base; your evidence file should show how you track the backported fixes. The previous LTS, 8.2, reached end of life on 16 September 2025, extended to leave three months of overlap with 8.3 LTS.

Proxmox VE 9.0 was released on 5 August 2025 on Debian 13 Trixie with QEMU 10.0.2 and Ceph Squid 19.2.3; the amd64 9.2 release, from 21 May 2026, moves to Debian Trixie 13.5, QEMU 11.0 and kernel 7.0, shipping Ceph Squid 19.2.3 alongside Ceph Tentacle 20.2.1. Its source is AGPLv3, and Proxmox states that no other licence types, OEM included, are available. Xen Orchestra is mostly AGPLv3, some libraries ISC.

The exit ramp is in the disk formats: VHD, QCOW2 and raw are open, so the disks are the portable part of either platform. What does not travel is the management layer: XAPI objects, Xen Orchestra jobs, Proxmox HA rules and PBS datastores are each platform's own. Keep them in code or exported config where you can, and price the move the way Stribog's exit-cost model describes, before you need it.

A decision rule that survives a decade:

• Choose XCP-ng if your team would rather be on call for one management VM it recovers separately — an XO config backup restores only users, jobs and settings, and a pool-metadata restore overwrites a host's XAPI database, so it is only for a new server with nothing running — wants backup and replication in the same console, and already runs NFS or is ready for XOSTOR.
• Choose Proxmox VE if you would rather have no management VM at all, can give corosync a dedicated low-latency network, and want backup as a separate product in a separate failure domain.
• Choose neither if your VMs are becoming Kubernetes neighbours: KubeVirt is the third route, and the container-versus-VM boundary explains what isolation you keep.

Both platforms give you back the thing VMware took: a hypervisor whose source you can read and whose roadmap no acquirer can reprice overnight. The remaining choice is about failure ownership. Pick the management plane whose 3 a.m. failure your team can diagnose without opening a vendor ticket, write the recovery procedure down, and rehearse it while nothing is broken.