Introduction
If you've spent any time in homelab forums or r/homelab, you've probably seen someone ask "should I just use Proxmox, or is XCP-ng worth a look?" It comes up constantly, and for good reason — they're the two most popular free, open-source, type-1 hypervisors left standing now that VMware ESXi's free tier is gone.
Both let you run virtual machines on bare metal without paying a cent. Both have real companies behind them. And both show up near the top of "free ESXi alternative" searches. But they're built on completely different foundations, and that difference shapes almost everything about how you'll actually use one day to day.
This guide breaks down the real differences — architecture, management, storage, backups, licensing — and then walks through something a lot of people actually need: moving a VM off XCP-ng and onto Proxmox VE once you've made your decision.
What You Will Learn
- The core architectural difference between Proxmox VE (KVM) and XCP-ng (Xen), and why it matters more than you'd think
- How management works on each platform — Proxmox's built-in web UI versus XCP-ng's separate Xen Orchestra
- Where each platform wins on storage, containers, clustering, and backups
- A step-by-step walkthrough of exporting a VM disk from XCP-ng and importing it into Proxmox VE 9.2
- The specific errors people hit during that migration, and how to fix them
What Is This Feature?
Proxmox VE is a free, open-source virtualization platform built on top of Debian Linux — currently Debian 13.5 "Trixie" under Proxmox VE 9.2. It uses KVM (Kernel-based Virtual Machine) for full virtual machines and LXC for lightweight Linux containers. KVM turns the Linux kernel itself into a hypervisor, so a VM runs almost as fast as the physical hardware underneath it. LXC containers, on the other hand, share the host's kernel instead of running a full separate OS — that makes them much lighter than a VM, which is why people use them for things like Pi-hole or a Samba file server where a whole virtual machine would be overkill.
XCP-ng is a free, open-source distribution of the Xen hypervisor. It started as a community fork of Citrix XenServer back in 2018 and has been actively maintained by the French company Vates ever since. Xen works differently from KVM — it's a "bare metal" hypervisor that boots before the host OS even starts, with a special management VM (called dom0) handling hardware access and administration. The current stable release is XCP-ng 8.3 LTS.
Both are genuinely "type 1" hypervisors, meaning they run directly on hardware rather than as an application inside another OS. That's the same category VMware ESXi and Hyper-V belong to. Where they diverge is in how you manage them and what you get out of the box.
Why Would You Use It?
Cost is the obvious answer for both. Neither platform requires a subscription to use every core feature — clustering, live migration, backups, all of it. Proxmox sells an optional support subscription that mostly just changes which package repository you pull updates from (more on that later). XCP-ng's parent company, Vates, sells Xen Orchestra Appliance (XOA) licenses and enterprise support, but the free "Xen Orchestra from the sources" build has the same underlying functionality if you're willing to compile it yourself.
Beyond cost, the real decision usually comes down to three things:
- Do you need containers? Proxmox's LXC support is a genuinely big deal for homelabs — you can run dozens of lightweight services (Pi-hole, Uptime Kuma, a reverse proxy) using a fraction of the RAM a full VM would need. XCP-ng has no native container support; everything is a full VM.
- Do you want the management UI built in? Proxmox ships with its web interface on port 8006 from the moment you finish installing. XCP-ng needs Xen Orchestra deployed separately — either as a prebuilt appliance (paid, or a free trial), or compiled from source yourself if you want zero cost. XO Lite, a slimmer built-in UI, is still catching up in features as of this writing.
- What storage do you need? Proxmox has native, first-class ZFS support baked into the installer — pick RAID-Z1, mirror, or a single disk right from setup. XCP-ng's storage repositories are more traditional (local ext4/LVM, NFS, iSCSI); ZFS support exists through a community driver but isn't part of the base install.
If you're coming from VMware ESXi and want something that feels closer to what you already know — a slim dom0, a separate management console — XCP-ng will feel more familiar. If you want one box that handles VMs, containers, storage, and backups without installing anything extra, Proxmox is usually the faster path.
Prerequisites
Before you follow the migration steps below, you'll need:
- A working XCP-ng host (8.3 LTS or newer) with at least one VM you want to move, and SSH access to it
- A Proxmox VE 9.x host already installed, with a storage location (like local-lvm or a ZFS pool) ready to receive the new disk
- Root or sudo access on both hosts
- Enough free disk space on the XCP-ng host to hold a temporary export of the VM's disk — figure on roughly the size of the VM's used disk space, not its full allocated size
- A way to transfer the exported file between hosts — SCP over the network is the simplest option
- The target VM powered off before you export its disk (exporting a live disk gives you an inconsistent, often unbootable copy)
Step-by-Step Tutorial
This walkthrough moves a single VM's disk from XCP-ng to a fresh VM shell on Proxmox VE. It's the same basic process people use for VMware or Hyper-V migrations, just with XCP-ng's own export tooling.
Step 1: Shut down the VM on XCP-ng
SSH into your XCP-ng host and power off the VM you're migrating:
xe vm-shutdown vm=MyVMExporting a running VM's disk risks a filesystem that's mid-write — you'd be copying a disk image that doesn't match what's actually on the block device. It's a fast way to end up with a VM that won't boot on the other side.
Step 2: Find the VM's disk UUID
Every VM on XCP-ng is identified by a UUID, and so is every virtual disk (VDI). First, get the VM's UUID:
xe vm-list name-label=MyVMThen use that to find the VDI attached to it:
xe vbd-list vm-uuid=<vm-uuid> params=vdi-uuidCopy the VDI UUID it returns — you'll need it in the next step.
Step 3: Export the disk as a VHD
Now export that disk to a file on the XCP-ng host itself:
xe vdi-export uuid=<vdi-uuid> filename=/root/myvm-disk.vhd format=vhdDepending on the disk size, this can take anywhere from a couple of minutes to well over an hour. A 40 GB disk on a decent SSD-backed host usually finishes in five to ten minutes.
Step 4: Copy the file to your Proxmox host
From your Proxmox host, pull the file over with SCP:
scp root@xcpng-host:/root/myvm-disk.vhd /var/lib/vz/template/iso/Any writable directory works — you're just staging the file before conversion. Just make sure there's enough free space on whichever storage you pick.
Step 5: Create the destination VM shell in Proxmox
You don't need to install an OS here — you're just creating an empty VM to attach the migrated disk to. Either use the Proxmox web UI (Create VM, and on the OS tab select "Do not use any media"), or do it from the command line:
qm create 210 --name myvm --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pciMatch the memory and core count to what the VM had on XCP-ng, and note the VMID you chose (210 in this example) — you'll need it in the next step.
Step 6: Convert the VHD to qcow2
Proxmox doesn't import VHD files directly, so convert it with qemu-img first:
qemu-img convert -f vpc -O qcow2 myvm-disk.vhd myvm-disk.qcow2The -f vpc flag might look odd, but "vpc" is qemu-img's internal name for the VHD format — a leftover from Microsoft's Virtual PC days. Don't confuse it with anything Windows-specific; it's just a format label.
Step 7: Import the disk into Proxmox
Attach the converted disk to the VM shell you created in Step 5:
qm importdisk 210 myvm-disk.qcow2 local-lvmThis copies the disk into the target storage and attaches it to VM 210 as an "unused disk" — it exists, but nothing is pointing to it as a boot device yet.
Step 8: Attach the disk and set the boot order
In the Proxmox web UI, open the VM's Hardware tab. You'll see an entry labeled Unused Disk 0. Double-click it, confirm the bus as SCSI (VirtIO SCSI is the fastest option for Linux guests), and click Add. Then go to Options → Boot Order and drag the new disk to the top, making sure it's checked.
Step 9: Boot the VM and check for driver issues
Start the VM and open its console. Linux guests usually boot fine right away, since most modern distros ship generic kernels that work under both Xen and KVM. Windows guests are a different story — they'll often blue-screen or hang on boot because they're still expecting Xen's PV disk and network drivers. Install the VirtIO drivers before rebooting into the migrated disk if you're moving a Windows VM; there's a separate guide on this blog covering that step in detail.
Commands Explained
| Command | What it does |
|---|---|
xe vm-shutdown | Cleanly powers off a VM on XCP-ng through the XAPI management layer |
xe vm-list | Lists VMs and their UUIDs, filterable by name-label or other parameters |
xe vbd-list | Lists virtual block devices (the link between a VM and its disks) |
xe vdi-export | Exports a virtual disk image to a file in VHD, raw, or other supported formats |
qm create | Creates a new, empty VM definition on Proxmox VE |
qemu-img convert | Converts a disk image between formats (VHD, qcow2, raw, VMDK, and more) |
qm importdisk | Copies a disk image file into Proxmox storage and attaches it to a VM as an unused disk |
Common Errors
"Failed to export: VDI has VBDs attached and is not marked read-only." This shows up if you try to export a disk while the VM is still running. Shut the VM down first — Step 1 above isn't optional.
"qemu-img: Could not open 'myvm-disk.vhd': Invalid footer" Usually means the SCP transfer didn't finish, or got interrupted partway. Re-copy the file and check the file size matches on both ends with ls -lh before converting again.
VM boots to a black screen or reboots in a loop after import This is almost always a Windows guest missing VirtIO drivers, or a Linux guest whose GRUB config still points at the old Xen device path (/dev/xvda instead of /dev/sda). See the troubleshooting section below.
"TASK ERROR: unable to parse volume filename" during qm importdisk Almost always a typo in the storage name. Run pvesm status on the Proxmox host to see the exact storage ID before retrying.
Troubleshooting
If a migrated Linux VM boots partway and then drops into an emergency shell or initramfs prompt, it's usually the device naming issue mentioned above. XCP-ng's Xen PV drivers name disks /dev/xvda, /dev/xvdb, and so on. Once the disk lives under KVM with a VirtIO SCSI controller, it becomes /dev/sda instead. If /etc/fstab or the GRUB config still references the old /dev/xvda path, the boot fails.
The fix is to boot the VM off a rescue ISO (any live Linux ISO uploaded to Proxmox works), mount the migrated disk, and edit /etc/fstab to use UUIDs instead of raw device paths — check the actual values with blkid. Then re-run update-grub from inside the mounted environment with a chroot before rebooting normally.
For networking, don't be surprised if the network interface inside the guest doesn't come up automatically after migration. XCP-ng and Proxmox present virtual NICs differently at the hardware level, so Linux sometimes renames the interface (from eth0 to something like ens18) and the old network config no longer matches. Check ip a inside the guest, and update Netplan or your distro's network config to reference the new interface name, or just switch to DHCP temporarily to confirm connectivity before locking in a static IP.
If the whole export process feels painfully slow, check whether you're exporting over a 1 Gbps management network — a 100 GB disk export can genuinely take 20-30 minutes over gigabit. Running the export and SCP transfer on a faster interface, if the hosts have one, cuts that down significantly.
Best Practices
Test the migration on a throwaway VM first, not your production file server. It costs you fifteen minutes and saves you from finding out about a device-naming quirk on something that actually matters.
Keep the original XCP-ng VM around (powered off) until you've confirmed the migrated copy works properly on Proxmox — logins, network, any services it runs. Don't delete your only copy until you've actually logged into the new one.
For anything bigger than a handful of VMs, don't do this by hand every time. Script the export-convert-import loop, or look at whether your XCP-ng disks are already using QCOW2 (supported since the May 2026 XCP-ng 8.3 update) — qemu-img can often skip a conversion step entirely if the source is already in a format Proxmox understands.
If you're still deciding between the two platforms rather than migrating away from one, spin up both in nested VMs first. Installing Proxmox VE and XCP-ng each inside a VM on your existing hardware costs you an evening, and you'll get a much better feel for the management experience than any comparison article — including this one — can give you.
Frequently Asked Questions
Is XCP-ng actually free, or is that just a trial?
It's genuinely free, including clustering and live migration. Vates makes money from Xen Orchestra Appliance licenses and enterprise support contracts, not from XCP-ng itself.
Can I run LXC containers on XCP-ng?
No, not natively. XCP-ng only runs full virtual machines. If lightweight containers matter to your setup, that alone is usually enough to push people toward Proxmox.
Which one has better performance?
They're close enough in raw VM performance that it rarely decides anything on its own. Xen's older paravirtualized I/O path and KVM's VirtIO path are both mature technologies at this point — the practical differences show up in management and storage, not benchmarks.
Do I need Xen Orchestra to use XCP-ng at all?
Technically no — you can manage everything through the xe command line. But doing day-to-day operations without any GUI gets old fast, so most people run at least Xen Orchestra Lite or the free source build.
Can I migrate a VM the other direction, from Proxmox to XCP-ng?
Yes, the same general process works in reverse — convert the qcow2 disk to VHD with qemu-img, then import it as a new VDI on XCP-ng with xe vdi-import.
Does Proxmox support Xen-based nested virtualization?
Proxmox VE is KVM-based, so nested virtualization uses Intel VT-x/AMD-V nested support rather than anything Xen-specific — you'd run XCP-ng as a guest inside a KVM VM if you wanted to test it that way.
Conclusion
Neither platform is "wrong." XCP-ng is a solid, mature choice if you want a lean Xen-based host and don't mind managing it through a separate Xen Orchestra instance. Proxmox VE earns its popularity in the homelab world by bundling VMs, containers, storage, and backups into one interface you get for free the moment the installer finishes.
If you've already got VMs running on XCP-ng and you're moving to Proxmox, the export-convert-import process above will get you there — just remember to shut the VM down first, and watch for the device-naming quirks once it boots on the other side. Test small, keep your original copy until you've verified the new one works, and you'll avoid the two mistakes that trip up most people doing this for the first time.