XCP-ng version: 8.3 | VMware: Generic (ESXi/vSphere)
This post is a companion reference to the video. Post corrections or additions below.
If you are looking for my training & tutorials you can find that here
Why This Guide Exists
Broadcom’s acquisition of VMware changed the economics of virtualization overnight. Perpetual licenses are gone, pricing has shifted to subscription bundles, and a lot of shops that were happy running vSphere for years are now evaluating their options. XCP-ng is one of the most mature open-source alternatives, but making the jump means learning a new set of terminology. Some of it is just different names for the same thing. Some of it is genuinely different behavior. This guide is the translation layer so you’re not starting from scratch.
Management Tools
Docs: Managing XCP-ng
| VMware | XCP-ng Equivalent | Same or Different? |
|---|---|---|
| vCenter Server | Xen Orchestra (XO) | Different approach |
| vSphere Client (web UI) | Xen Orchestra CE / XOA | Different |
| ESXi Host Client | XO (no dedicated host client) | Different |
| PowerCLI | xe CLI / xo-cli | Different |
vCenter vs. Xen Orchestra: This is the biggest conceptual shift. In VMware, vCenter is a separate licensed product you bolt on to manage ESXi hosts. In XCP-ng, Xen Orchestra (XO) is the management plane, and it’s open source. There are two ways to run it: Xen Orchestra Community Edition (self-compiled, free) or XOA (the pre-built appliance from Vates, which has a free tier and paid tiers for more features).
XO handles everything vCenter does - multi-host management, pools, VM lifecycle, storage, backups - but the architecture is different. XO runs as its own VM (either on your XCP-ng infrastructure or on a separate machine) and connects to your XCP-ng hosts via the XAPI protocol. You don’t install it on the hypervisor host itself.
xe CLI is the native command-line tool on XCP-ng hosts. Think of it as the PowerCLI equivalent, but more raw. It communicates directly with XAPI. For scripting and automation, xo-cli can also interact with XO’s API. XCP-ng also has Terraform, Packer, and Ansible support for those going the infrastructure-as-code route.
Licensing
| VMware | XCP-ng | Notes |
|---|---|---|
| vSphere Essentials / Standard / Enterprise Plus | XCP-ng (free, open source) | Fundamentally different model |
| vCenter license | Xen Orchestra CE (free, self-built) or XOA (tiered) | XO is optional |
| vSAN license | XOSTOR (paid add-on) or external storage (free) | See storage section |
| NSX license | XO SDN Controller (partial analog, included with XO) | Significant scope difference |
XCP-ng itself is fully open source and free under GPLv2. You pay nothing to run it on as many hosts as you want. Where you might pay is on the Xen Orchestra side if you want the premium XOA appliance features (advanced backup, delta replication, etc.). Vates, the company behind XCP-ng and XO, makes money on XOA subscriptions and enterprise support - that’s how the project is sustained.
There is no per-socket, per-VM, or per-CPU licensing in XCP-ng.
Compute / VM Concepts
Docs: Virtual Machines
| VMware | XCP-ng | Same or Different? |
|---|---|---|
| Virtual Machine (VM) | Virtual Machine (VM) | Same |
| vCPU | vCPU | Same |
| Memory ballooning | Dynamic Memory Control (DMC) | Similar, different implementation |
| VMware Tools | XCP-ng Windows Guest Tools / xe-guest-utilities (Linux) | Same role, two options for Windows |
| OVA/OVF | XVA | Different format |
Guest Tools: This is the one that trips people up most. You need to install guest tools inside your VMs just like VMware Tools. For Linux, the package is xe-guest-utilities. For Windows, there are now two supported options: the XCP-ng Windows Guest Tools (recommended, from the XCP-ng project directly) or the Citrix XenServer VM Tools. Both work, but the XCP-ng tools are the recommended path going forward. Without guest tools you lose clean shutdown, IP address visibility in XO, and proper memory reporting. Don’t skip this.
XVA format: XCP-ng’s native VM export format is .xva. For migrating VMs from VMware, Xen Orchestra has a built-in V2V (Virtual-to-Virtual) migration workflow that handles the process directly - you don’t need to manually export OVFs and convert disks. The V2V path uses nbdkit and VMware VDDK libraries to migrate VMs from VMware to XCP-ng with guided pre-checks and warm migration support (migrates data up to the last snapshot, then stops the VM to sync the delta, minimizing downtime). There is some prep work required on the VMware side before migrating: uninstall VMware Tools, remove mounted ISOs, and reduce snapshots to a minimum since snapshot migration is slower and increases risk. For the full V2V procedure see the Vates migration guide and the XO V2V migration docs.
Dynamic Memory Control: Similar concept to memory ballooning but works differently under the hood. Important caveat: during a live migration, XCP-ng will reduce the VM’s memory to its dynamic minimum setting. If you’ve set a low dynamic minimum and the VM can’t function at that RAM level, it can crash mid-migration. For most workloads, set memory statically (dynamic min = dynamic max) and you won’t have this problem.
Storage
Docs: Storage in XCP-ng | QCOW2 FAQ | XOSTOR
| VMware | XCP-ng | Thin Provisioned | Shared | Notes |
|---|---|---|---|---|
| Datastore | Storage Repository (SR) | Depends on type | Depends on type | Same concept, different name |
| VMFS datastore (local) | Local LVM SR | No | No | Thick only |
| VMFS datastore (local) | Local EXT SR | Yes | No | Recommended for local |
| NFS datastore | NFS SR | Yes | Yes | Recommended for shared |
| iSCSI datastore | iSCSI SR (LVMoiSCSI) | No | Yes | Thick only |
| vSAN | XOSTOR | Yes | Yes | Paid add-on from Vates |
| RDM | HBA pass-through | N/A | Yes | Similar concept |
| Storage vMotion | Storage migration (XO) | N/A | N/A | Similar capability |
Storage Repository (SR) is the XCP-ng term for what VMware calls a datastore. It’s a pool of storage attached to a host or pool that holds virtual disk images (VDIs). The concept is the same - you point XCP-ng at a chunk of storage and it manages VM disks inside it.
Thin vs. thick provisioning matters here. Unlike VMware where you choose thin or thick at the VMDK level, in XCP-ng provisioning is determined by the SR type. Local EXT and NFS SRs are thin. Local LVM and iSCSI SRs are thick. This is not a VM-level setting - it’s baked into the SR type you choose. The docs specifically note that thick-provisioned SRs cost significantly more space when you take snapshots (which backup jobs use), so thin SRs (EXT, NFS) are recommended where possible. That said, you are not locked in: you can migrate VMs between SR types both live (while the VM is running) and offline, so moving from a thick SR to a thin SR - or vice versa - is straightforward without downtime if you need to change your storage layout later.
XOSTOR vs. vSAN: XCP-ng does have a hyperconverged storage option: XOSTOR, built by Vates on top of DRBD technology. It pools local disks across hosts into a virtual SAN with replication, managed directly from XO. Key constraints: minimum 3 hosts, maximum 7 per cluster, and available capacity is calculated as (smallest disk size x number of hosts) / replication count - so a 3-host cluster with 200GB disks at 2x replication gives you 300GB usable. XOSTOR is a paid add-on on top of an XOA subscription, not included free with XCP-ng. If you don’t want to pay for XOSTOR, external NFS/iSCSI (TrueNAS, dedicated SAN, etc.) is the free path for shared pool storage.
Disk format: VHD and QCOW2: XCP-ng 8.3 now supports two virtual disk formats. VHD has been the historical format and remains the default. QCOW2 (from QEMU) went GA in XCP-ng 8.3 as of May 2026, raising the maximum disk size from 2TiB to 16TiB (technically 16,381 GiB). Xen Orchestra handles format selection automatically: new disks under 2040 GiB are created as VHD; new disks over 2040 GiB are automatically created as QCOW2. You don’t need to rebuild existing SRs - most SR types can manage VHD and QCOW2 side by side. The exceptions are XOSTOR (linstor) and SMB SRs, which do not support QCOW2 yet.
A few things to know about QCOW2 is that it’s fairly new as of this post so take a look at full release notes here about edge cases that may apply to your environment QCOW2 is now GA in XCP-ng and you can follow all their latest storage updates via their Storage Blog Tag Storage - XCP-ng Blog
RAW format is also still available for cases where you need disks beyond the current limits and can accept the tradeoff: no snapshot support, no delta backups, no live storage migration for that disk.
Networking
Docs: Networking | SDN Controller
| VMware | XCP-ng | Same or Different? |
|---|---|---|
| vSwitch (vSS) | Open vSwitch (OVS) | Different technology, similar role |
| Distributed vSwitch (vDS) | No native equivalent | Different |
| Port Group | Network | Same concept, different name |
| Uplink / vmnic | PIF (Physical Interface) | Similar concept, broader in XCP-ng |
| NIC Teaming / bonding | Bond | Same concept |
| VLAN Tagging | VLAN (tagged networks) | Same concept |
| VMkernel adapter (vmk) | Management interface / IP on PIF | Similar |
Open vSwitch (OVS): XCP-ng uses OVS as its virtual switching layer. It’s capable and scriptable, but configured differently from the vSphere UI approach.
Networks in XCP-ng: A “Network” in XO is roughly equivalent to a VMware port group. Create a network, attach it to a PIF if it needs external access, assign a VLAN ID if needed, then assign VMs to it. Same mental model, different terminology.
PIF (Physical Interface): In VMware, an uplink/vmnic represents a physical NIC. In XCP-ng, PIF is a broader concept. A PIF can represent a physical NIC, but also a VLAN on top of a physical NIC, a bond of multiple NICs, or a tunnel interface (GRE/VXLAN). So when you see PIF in XCP-ng, it doesn’t strictly mean physical NIC - it means any interface used to connect outside a host.
No Distributed vSwitch: VMware’s vDS is a centralized virtual switch that spans all hosts in a cluster and lets you manage port groups and policies from one place. XCP-ng doesn’t have a direct equivalent, but pool networking works differently than you might expect. When you add a host to a pool, XCP-ng automatically merges networks by matching NIC device names across hosts - so all physical NICs with the same device name end up on the same network pool-wide. More importantly, any network you create or change at the pool level in XO is automatically applied to all hosts in that pool. You’re not manually replicating config to each host. The practical difference from vDS is mainly around advanced features like per-port policies and traffic shaping, not day-to-day network management. See the XCP-ng networking docs for the full detail.
VLAN tagging: Works well and is first-class. Create a VLAN network in XO, give it a VLAN ID, assign VMs. Your upstream switch port still needs to be a trunk. No VLAN configuration needed inside the VMs - XCP-ng handles tagging/untagging transparently.
Bonding: NIC bonding is supported with active-passive, active-active (balance-slb), and LACP modes. Configure through XO or xe CLI. Same general concepts as VMware NIC teaming.
SDN Controller (partial NSX analog): XO includes an SDN controller plugin that adds overlay networking via GRE or VXLAN tunnels - including encrypted tunnels using IPsec. This lets you create private networks that span hosts across different pools, isolated from the physical network. It also supports OpenFlow rules for per-VIF traffic filtering directly at the hypervisor vswitch level, which is the closest thing XCP-ng has to NSX micro-segmentation. It’s not NSX - there’s no stateful distributed firewall, no L7 rules, no load balancing or NAT - but for basic isolated overlay networks and simple VM-level traffic controls it’s a real feature. Note that OpenFlow rules are still marked BETA. See the XCP-ng SDN controller docs for full detail.
High Availability, Clustering & Live Migration
Docs: Management and Backup
| VMware | XCP-ng | Same or Different? |
|---|---|---|
| vSphere Cluster | Pool | Similar concept, different name |
| vMotion | XenMotion / Live Migration | Same capability |
| Storage vMotion | Storage Migration | Same capability |
| vSphere HA | Pool HA | Similar, different implementation |
| DRS | Workload Balancing (WLB) | Much more basic |
| Fault Tolerance (FT) | No equivalent | N/A |
| EVC | Automatic CPU masking within pool | Similar outcome, automatic |
Pool: A group of hosts managed together is called a Pool. One host is the Pool Master (Coordinator). All pool management traffic runs through it. If the Coordinator goes down, hosts keep running VMs but pool management is disrupted until a new coordinator is elected.
XenMotion (Live Migration): This is vMotion. Live migration of running VMs between hosts in a pool with no downtime. Requires shared storage accessible by all hosts, or supports storage migration in XO. Works well.
Pool HA: Built in at the pool level. When enabled, the pool monitors host health and automatically restarts VMs on surviving hosts if a host fails. You set HA protection per-VM. Requires shared storage for the HA heartbeat disk. Note: HA cannot be enabled at the same time as an emergency network reset - you must disable HA first.
DRS / Workload Balancing: This is where XCP-ng is notably less mature. VMware’s DRS continuously monitors and migrates VMs to optimize resource utilization. XCP-ng’s WLB is much more basic. For most small-to-medium deployments it’s not a dealbreaker - you do manual balancing - but if you relied heavily on DRS automation, expect a step down.
CPU Compatibility for Live Migration: VMware’s EVC lets you manually set a CPU compatibility baseline across hosts. XCP-ng handles this automatically: when hosts with dissimilar CPUs join a pool, XCP-ng automatically applies CPU masking to the lowest common feature set across all pool members. You don’t configure this manually - it happens at pool join time.
Snapshots & Backup
Docs: Backup with Xen Orchestra
| VMware | XCP-ng | Same or Different? |
|---|---|---|
| VM Snapshot | VM Snapshot | Same concept |
| Snapshot consolidation | Coalesce | Same concept, different name |
| Changed Block Tracking (CBT) | CBT (supported in XCP-ng 8.3) | Same - now supported |
| vSphere Data Protection | Xen Orchestra Backup | Different product, similar capability |
| Veeam | Veeam (limited) | Ecosystem difference |
Snapshots work conceptually the same way - capture VM disk and memory state at a point in time. In XCP-ng, snapshots are stored as VHD differencing disks. Same caveats apply: don’t run on snapshots long term, they grow and impact performance. XO can detect VMs with uncoalesced snapshot chains and will skip backup jobs for those VMs until coalescing completes - this is a built-in protection.
Coalesce: When you delete snapshots in XCP-ng, the host merges the snapshot chain back into the base disk in the background. This is snapshot consolidation. With a lot of stacked snapshots, coalesce can take a while and hammer storage I/O. There’s a max snapshot chain length of 30 - if you hit that, backup jobs will stop working for that VM until chains are merged.
CBT in XCP-ng 8.3: This is significant for backup workflows. Changed Block Tracking allows backup tools to back up only the blocks that changed since the last backup. XCP-ng 8.3 added CBT support, closing a meaningful gap compared to VMware. Backup tools leveraging XAPI can now use this for efficient incremental backups.
Xen Orchestra Backup: XO has a built-in backup engine that handles full backups, delta (incremental) backups, continuous replication, and disaster recovery. Writes directly to NFS/SMB shares or remote XO hosts. For many shops this replaces the need for a third-party backup tool entirely. If you were running Veeam Community Edition for VMware, XO Backup is a reasonable analog for XCP-ng.
Templates & Cloning
Docs: Virtual Machines
| VMware | XCP-ng | Same or Different? |
|---|---|---|
| VM Template | VM Template | Same concept |
| Clone from Template | VM from Template | Same concept |
| Linked Clone | Fast Clone (differencing disk) | Similar mechanism |
| Content Library | No direct equivalent | Different |
| Customization Specification | cloud-init / manual (Sysprep for Windows) | Different approach |
Templates work similarly to VMware. Build a VM the way you want it, convert it to a template, deploy new VMs from it. The template becomes read-only. XO manages this cleanly through the UI.
No Content Library equivalent: VMware’s Content Library is a centralized repo for templates and ISOs that syncs across vCenter instances. XCP-ng doesn’t have a direct equivalent. ISO management is done via ISO SRs (a directory of ISOs, shared via NFS or SMB, or local to a host), and templates exist per-pool. For multi-site environments, plan around this workflow difference.
Guest Customization: VMware has Customization Specifications to auto-configure guest OS settings on deployment. XCP-ng doesn’t have this built in. The common approach is cloud-init inside your Linux templates, or Sysprep plus a first-boot script for Windows. More DIY, same result.
Fast Clone vs. Full Clone: XO supports both. Fast clone creates a VM with a differencing disk pointing to the source (like VMware linked clones) - saves space but shares a storage dependency with the parent. Full clone copies the entire disk. Same tradeoffs as VMware.
Quick Reference Cheat Sheet
| VMware Term | XCP-ng Term |
|---|---|
| ESXi Host | XCP-ng Host |
| vCenter | Xen Orchestra (XO) |
| Cluster | Pool |
| Datastore | Storage Repository (SR) |
| Port Group | Network |
| vmnic / uplink | PIF (Physical Interface) |
| vMotion | XenMotion / Live Migration |
| vSphere HA | Pool HA |
| VMware Tools | XCP-ng Windows Guest Tools / xe-guest-utilities |
| VMDK | VHD (default, 2TiB max) or QCOW2 (GA in 8.3, 16TiB max) |
| OVA/OVF | XVA |
| Snapshot Consolidation | Coalesce |
| Template | Template |
| vDS | (No equivalent) |
| vSAN | XOSTOR (paid) or external shared storage (free) |
| DRS | WLB (basic) |
| NSX | XO SDN Controller (GRE/VXLAN tunnels, OpenFlow rules - partial analog) |
| PowerCLI | xe CLI / xo-cli |
| Linked Clone | Fast Clone |
| Customization Specification | cloud-init / Sysprep |
What’s Different (Honest Assessment)
XCP-ng is not a feature-for-feature replacement for a full VMware vSphere Enterprise Plus stack. Here’s what you’re giving up:
- vSAN: No free built-in HCI. XOSTOR exists and works well but it’s a paid Vates add-on, not something baked into XCP-ng. External NFS/iSCSI is the free path.
- NSX: XCP-ng’s SDN controller (via XO) covers overlay networking with GRE/VXLAN tunnels and basic per-VIF traffic rules via OpenFlow - so there is a partial analog. What’s missing compared to NSX is everything else: stateful distributed firewall, L7 application-aware rules, identity-based policy, load balancing, NAT services, and the scale NSX operates at. The OpenFlow rules feature is still in BETA. See the XCP-ng SDN controller docs for what’s actually there.
- DRS automation: Workload balancing is much more basic.
- vDS advanced features: Pool-level network changes in XO apply to all hosts automatically, so basic network management is centralized. What’s missing compared to vDS is the advanced stuff: per-port policies, traffic shaping, and distributed port group features.
- Disk size limit: VHD (the default format) caps at 2TiB per virtual disk. QCOW2 is now GA in 8.3 and raises this to 16TiB, but it’s a newer format with some known edge cases still being worked out. Gradual rollout recommended.
- Third-party ecosystem: VMware’s ecosystem for backup, monitoring, and operations tooling is more mature.
- Guest Customization Specs: You’re doing this manually or with cloud-init.
What You Gain
- No licensing costs for the hypervisor itself
- Open source codebase - you’re not beholden to a vendor’s acquisition decisions
- XAPI is well-documented and scriptable - Terraform, Packer, and Ansible support built in
- XO Backup built in - solid backup solution without a separate product purchase
- An MCP server for AI MCP meets Xen Orchestra
- Active development from Vates with a real community behind it
- Very Active forums
This reference may be updated as XCP-ng and XO evolve. Post corrections or additions below.