Virtualization platforms in 2026: revisit Proxmox VE, XCP-ng and Incus before you migrate another virtual machine

Most virtualization migrations in India over the last two years did not start with an architecture review. They started with a renewal quote. A team that had run three or four VMware hosts quietly for a decade opened the email from its partner, saw a number many times last year’s support bill, and was told to “move to something open source” by the next financial year. The usual next step is a weekend of YouTube videos, one Proxmox install on a spare server, and a plan to move forty VMs before the renewal date.

That plan often works for the first ten VMs. Problems show up later. A two node cluster loses quorum when one node reboots. A Windows VM imported from ESXi does not boot because its disk controller changed. Backups are “the same as before” until somebody tries a restore and finds that the old backup tool no longer understands the new platform.

None of this is about which hypervisor is faster. All three platforms in this post run a normal business workload well. It is about the model each platform asks you to accept: how hosts form a cluster and decide who is alive, where disks live, how a VM moves, how backups and restores work, how VMware guests come across, and who you call when something breaks.

This post revisits three open source platforms that teams actually choose when they leave vSphere: Proxmox VE, XCP-ng with Xen Orchestra, and Incus, with a short look at oVirt, OpenNebula, Harvester and KubeVirt. The goal is to choose on purpose and plan a migration that survives its first bad day.

A few pieces of news set the scene. Proxmox VE 8 reached end of life in August 2026, so anyone still on it is now on an unsupported release. Incus 7.0 LTS arrived in May 2026 with support until June 2031. XCP-ng 8.3 is the only supported XCP-ng release, with support until 30 November 2028, while XCP-ng 9.0 exists only as an early demonstrator. Xen Orchestra moved to a new major version, XO 6, which is gradually taking over from the older XO 5 interface month by month.

This post stays on the virtualization layer. For backing up files inside your VMs, see backups in 2026, and for databases, PostgreSQL backups in 2026. If your plan is to run Kubernetes on top of the new platform, read lightweight Kubernetes in 2026 and Kubernetes storage in 2026. Host setup belongs to configuration management in 2026 and OpenTofu and Terraform. For watching hosts and guests, see infrastructure monitoring in 2026, and for controlling who can reach the hypervisor consoles, infrastructure access in 2026. Containers versus micro VMs for untrusted code is covered in container sandboxing in 2026, and plain container runtimes in container engines in 2026.

A scenario to keep us honest

We will use one invented company through the post. Rajwada Pharma Distributors is an invented example, not a real business. It is a pharmaceutical distributor based in Indore, supplying chemists and hospitals across western Madhya Pradesh from two warehouses, one in Indore and one in Dewas. The IT team has 4 people, led by an engineer called Harshal, and an outside partner who set up VMware years ago.

What they run:

  • Three VMware ESXi hosts with vSphere 7 and vCenter, two CPU sockets each, connected to an ageing iSCSI SAN.
  • About 45 VMs: two Windows domain controllers, a Windows file server, an ERP on Microsoft SQL Server, a warehouse management system on Linux with PostgreSQL, a few internal web apps, a print server, a monitoring VM and some test machines.
  • A commercial backup product that writes nightly VM backups to a NAS, with a weekly copy to an external disk that Harshal takes home.
  • A DR plan that says “restore from backup at the Dewas warehouse server room”, which has never been tested end to end.

What triggered the review: the VMware renewal quote under the new subscription model came in at several times the earlier support cost, and vSphere 7 is already past its end of general support. The owners have asked for a cheaper platform before the next financial year. One team member set up Proxmox VE at home and likes it. The partner suggests XCP-ng because “it is closer to how vCenter works”. A young developer keeps mentioning Incus because the warehouse app could run in system containers.

Harshal’s questions: which platform can the four of us run for five years, how do we move 45 VMs with little downtime, what happens to the SAN, how will backups and DR work, and what will it cost?

The short version

  • Start with the operating model, not the hypervisor. Write down how many hosts, what shared storage, what quorum design, how you will back up and restore, how you will patch monthly, and who you call. The hypervisor follows from those answers.
  • Proxmox VE 9.2 (Debian 13 base, KVM and QEMU, plus LXC containers) is the most complete single package: web UI, clustering, HA, Ceph and ZFS built in, an ESXi import wizard, and Proxmox Backup Server alongside. All features in every edition; you pay per CPU socket for the stable enterprise repository and support. AGPLv3. Proxmox VE 8 is now end of life.
  • XCP-ng 8.3 LTS with Xen Orchestra (Xen hypervisor, XAPI toolstack, pools with a master) feels closest to the vSphere and vCenter way of working: pools, shared storage repositories, a central manager with strong built-in backup, and a V2V tool for VMware. Supported until November 2028. Old CentOS 7 based dom0 until XCP-ng 9 arrives. Vates sells per host support.
  • Incus 7.0 LTS (system containers through LXC and VMs through QEMU, managed through a REST API and CLI) is the lightest and most cloud like. Strong for many Linux workloads, clustering and automation; less of a “vCenter replacement” for a Windows heavy shop. Apache 2.0, community led, commercial support from Zabbly.
  • All three can import VMware guests, but every path needs driver preparation for Windows, a test restore, and a rollback plan.
  • For Rajwada, the plan we arrive at is Proxmox VE 9.2 on three hosts with a dedicated cluster network, keeping the iSCSI SAN for now as shared LVM, Proxmox Backup Server on separate hardware with a copy at Dewas, and the ESXi import wizard used VM by VM in planned windows, Windows first in a pilot. XCP-ng is the serious alternative if the team values a central manager with strong backups over an integrated web UI, and Incus is worth piloting later for Linux services.

Where things stand on 31 October 2026

Why so many teams are moving

  • Broadcom completed its acquisition of VMware in November 2023. In December 2023 it announced the end of new perpetual licence sales, with VMware products moving to subscriptions and a much smaller set of bundled offerings.
  • In early 2024 the free ESXi hypervisor was withdrawn.
  • Pricing varies by contract, so we will not quote figures. Many small and medium teams now have a deadline and a budget gap, a bad combination for careful engineering.

Proxmox VE

  • Current release: 9.2, released on 21 May 2026, based on Debian 13 “Trixie” (13.5), with Linux kernel 7.0 as the default, QEMU 11.0, LXC 7.0, ZFS 2.4, and Ceph Squid 19.2.3 or Ceph Tentacle 20.2.1.
  • arm64. On 5 August 2026 Proxmox shipped its first official build for 64-bit Arm (enterprise servers such as NVIDIA Grace), sharing the same code base and repositories. Live migration works only between nodes of the same architecture.
  • 9.2 highlights. Dynamic load balancing in the Cluster Resource Scheduler, which can move HA managed guests based on real resource use; new SDN fabric protocols (WireGuard and BGP); custom CPU models in the web UI; and the ability to disarm and arm HA cluster wide for planned maintenance without fencing.
  • 9.0 (5 August 2025) brought VM snapshots on thick LVM as “volume chains” (still a technology preview), which matters for shared LUNs from a SAN, and HA affinity rules.
  • Support window. The Proxmox FAQ lists Proxmox VE 8 (Debian 12) as end of life in August 2026. Proxmox VE 9 follows the Debian 13 lifecycle; its end date is not yet announced.
  • Around it. Proxmox Backup Server 4.2 (29 April 2026) made S3 compatible object storage an officially supported backup backend. Proxmox Datacenter Manager reached 1.0 on 4 December 2025 and 1.1 on 28 May 2026, giving a single view across several clusters.
  • Business news. In September 2026 Proxmox announced 24/7 enterprise support and a North American subsidiary. The pricing page says Premium 24/7 support is available from 19 October 2026, with Standard 24/7 by the end of 2026.

XCP-ng and Xen Orchestra

  • XCP-ng 8.3 LTS was released on 7 October 2024, became an LTS release on 16 June 2025, and is supported until 30 November 2028. It is the only supported release; 8.2 LTS ended in September 2025.
  • Under the hood. Xen 4.17.5 with patches, and a control domain (dom0) based on CentOS 7 with security fixes backported by the XCP-ng security team, running a Linux 4.19 kernel with patches.
  • Recent updates. The October 2026 update batch (5 October) made live storage migration faster; Vates says 2 to 2.5 times faster in some of its own production-like tests, which is the vendor’s own measurement. QCOW2 disks, which remove the old 2 TiB virtual disk limit of VHD, reached general availability in 8.3 in May 2026 according to the Vates roadmap.
  • XCP-ng 9. An early “demonstrator” built on Xen 4.19, Linux 6.12 and a dom0 loosely based on AlmaLinux 10 has been public since December 2025. The project says plainly that it is not alpha quality, has no upgrade path, and will never become production ready. Plan on 8.3 for any production work today.
  • Xen Orchestra. XO 6.0 arrived on 18 December 2025 as the first release of a new major version; since then monthly releases have moved more operations from XO 5 into XO 6. The latest is XO 6.10 (29 October 2026), with faster full mirror backups, live restore in preview, VM to host affinity in the load balancer, V2V working again with ESXi 6.x, and an update to Node.js 22 in the appliance to fix a high severity vulnerability. XO Lite, a small interface built into each host, now covers basic tasks such as creating networks when the main XO is unreachable.
  • Licences. Xen Orchestra’s repository says AGPLv3. XAPI, the toolstack, is under LGPL 2.1 with a linking exception. Xen itself is GPLv2.

Incus

  • Incus 7.0 LTS was released on 1 May 2026 (announced on 5 May) and is supported until June 2031: two years of bug and security fixes, then security only. Incus 6.0 LTS, released in April 2024, is now in its security only phase until June 2029.
  • Latest feature release: 7.6 (30 October 2026), with fixes across OVN networking, ZFS, LVM and VMs. Point release 7.0.2 for the LTS line came out on 16 October 2026.
  • 7.0 changes worth knowing. A low level backup API based on NBD with dirty bitmaps for incremental VM backups; a core.shutdown_action option that can evacuate a cluster member on shutdown; a built-in S3 listener replacing MinIO for storage buckets; and new minimums such as Linux 6.12 and QEMU 8.2, with cgroup v1 and iptables support deprecated.
  • Security. The 7.0 release fixed nine CVEs (seven moderate, two low) reported in an audit by 7ASecurity.
  • Licence and support. Apache 2.0, run as a community project under Linux Containers. Commercial support is available from Zabbly. IncusOS, an immutable operating system built just to run Incus, is developed alongside.

Around them

  • oVirt. Still maintained by its community; the latest engine release on GitHub is 4.5.7 from December 2025. With Red Hat’s focus now on OpenShift Virtualization, it is hard to recommend for a new deployment.
  • OpenNebula. A cloud management layer that can drive KVM and LXC hosts; 7.4 is the current series. Apache 2.0. More layers than a small team needs, but useful for a self service private cloud.
  • Harvester. SUSE’s hyperconverged platform built on Kubernetes, KubeVirt and Longhorn; latest stable 1.9.0 (16 September 2026).
  • KubeVirt. Runs VMs as Kubernetes objects; latest stable 1.9.1 (12 October 2026). Harvester and KubeVirt make sense when Kubernetes is already your main platform, not as a first step for a Windows heavy shop.

The first questions to ask

Answer these in writing before comparing tools. Most painful migrations skip at least two of them.

  1. How many hosts, and what happens when one fails? Two hosts need a third vote for quorum. Three is the practical minimum for clustering with HA.
  2. Where will VM disks live? Keep the existing SAN, use local disks with replication, or move to distributed storage like Ceph? Each choice changes live migration, HA and backups.
  3. What must keep running during a host failure, and how fast must it restart? Not every VM needs HA. A domain controller pair already has its own redundancy.
  4. How will you back up, and how will you prove restores work? Name the tool, the target, the off site copy and the restore test schedule.
  5. How will each VM come across from VMware? By import wizard, by disk export, or by rebuilding it fresh? Which VMs are Windows, and which use vTPM or encrypted disks?
  6. How will hosts be patched? Monthly, with rolling reboots and live migration, or with downtime windows?
  7. Who will you call? Vendor subscription, a local partner, or your own team only?
  8. What does the team already know? Debian and Linux skills point one way; a team used to vCenter and its pool and datastore language may find another more natural.

How each one works

Proxmox VE: a Debian based all in one platform

Proxmox VE is a set of packages on top of Debian. VMs run on KVM with QEMU, managed by the qemu-server tools (qm on the command line). Containers run on LXC, managed by pct. Every node has the full web UI and REST API; there is no separate vCenter like appliance.

Key ideas:

  • Cluster file system. Configuration lives in /etc/pve, a small database replicated to every node by the Proxmox cluster file system (pmxcfs) over Corosync. Changes are only allowed when the cluster has quorum.
  • Quorum and Corosync. Each node has one vote by default. A majority is needed to make changes. Corosync is sensitive to latency, so the documentation recommends a separate, low latency network for cluster traffic. For two node clusters, an external QDevice provides the tie breaking vote.
  • HA. The HA manager restarts guests on surviving nodes. It uses fencing based on a watchdog: a node that loses quorum resets itself so that it cannot write to shared storage while another node takes over its VMs. Since 9.0 there are affinity rules, and since 9.2 dynamic load balancing.
  • Storage plugins. Local directory, LVM, LVM-thin, ZFS, NFS, CIFS, iSCSI, Ceph RBD and CephFS (with Ceph deployable from the UI), plus third party plugins. ZFS storage replication can copy VM disks to another node on a schedule, which gives a cheap form of fast failover without shared storage.
  • SDN and firewall. A software defined networking stack (VLAN, VXLAN, EVPN zones and the new fabrics) and a built-in firewall at datacenter, node and guest level.
  • Repositories. The enterprise repository is the tested, stable stream for subscribers. The no-subscription repository is free and described as suitable for testing and non production use. A test repository is for developers.

A minimal two node cluster with a QDevice on a small third machine, as an example of what quorum planning looks like in practice:

# on the first node
pvecm create rajwada-cl

# on the second node, using a dedicated cluster network address
pvecm add 10.10.10.11 --link0 10.10.10.12

# on both nodes: install corosync-qdevice; on the small third machine: corosync-qnetd
# then, from one cluster node
pvecm qdevice setup 10.10.10.50
pvecm status

XCP-ng and Xen Orchestra: pools, storage repositories and a central manager

XCP-ng is a community distribution that grew out of Citrix XenServer. The Xen hypervisor runs directly on the hardware; a privileged VM called dom0 runs the drivers and the XAPI toolstack. Guests run as HVM or PVH VMs with paravirtual drivers.

Key ideas:

  • Pools and the pool master. Hosts join a pool; one host is the pool master and holds the XAPI database, which is replicated to other members. If the master fails, a member can be promoted. This is similar to how many vCenter admins think about clusters.
  • Storage repositories (SRs). Each SR has a type: local LVM (thick), local EXT (thin), NFS (thin, recommended by the docs for ease and space saving), iSCSI and HBA (shared LVM, thick), SMB, ZFS (offered as is), and XOSTOR, Vates’ hyperconverged storage based on LINSTOR and DRBD. Thick SRs make snapshots expensive in space, which matters because backups use snapshots.
  • Disk formats. VHD was the default for years, with a 2 TiB limit per virtual disk. QCOW2 support removes that limit and is now generally available on 8.3.
  • HA. XAPI HA needs a shared SR for its heartbeat and state file, and restarts protected VMs on surviving hosts.
  • Xen Orchestra. XO is the central manager: inventory, consoles, users and ACLs, the backup engine, load balancing, rolling pool updates, V2V import, a REST API, and Terraform, Packer and Ansible integrations. It is distributed as XOA, a turnkey appliance with an updater and support, or built from source on GitHub. Vates states that every feature is available when built from source; the support and the tested appliance are what you pay for.

Typical commands at the host level, for when the GUI is not reachable:

# list storage repositories and find the shared one for the HA heartbeat
xe sr-list shared=true params=uuid,name-label,type

# enable pool HA with that SR
xe pool-ha-enable heartbeat-sr-uuids=<shared-sr-uuid>

# live migrate a VM to another host in the same pool
xe vm-migrate vm=erp-sql01 host=xcp-host02 live=true

Incus: system containers and VMs behind one API

Incus is a manager for system containers (through LXC), application containers from OCI images, and VMs (through QEMU). Everything is an “instance” with the same API, CLI, profiles, projects, storage pools and networks. Incus started as a community fork of LXD in 2023.

Key ideas:

  • System containers first. A system container runs a full Linux distribution with its own init, sharing the host kernel. It starts in seconds and uses much less memory than a VM. Many Linux services run happily this way. Windows, other kernels, and workloads that need strong isolation from the host run as VMs.
  • REST API and CLI. The incus command talks to the daemon over a local socket or HTTPS with certificates or OIDC. There is no bundled heavy web UI; a web UI exists, but the project’s centre of gravity is automation through the API, Terraform or OpenTofu, and Ansible.
  • Storage drivers. Directory, Btrfs, LVM (including clustered LVM for shared block storage), ZFS, Ceph RBD, CephFS, Ceph Object, LINSTOR and TrueNAS.
  • Networks. Managed bridges, macvlan, SR-IOV, physical, and OVN for distributed networking with ACLs, load balancers and network forwards.
  • Clustering. Members share a distributed database (cowsql, based on Raft). You can evacuate a member for maintenance and restore it later. Automatic “cluster healing” can evacuate instances when a member goes offline, but only for instances on shared storage without local devices, and the documentation warns of data corruption risk under partial connectivity.

A short example of day to day Incus work:

# create a VM and a system container from images
incus launch images:debian/13 wms-app01 --vm -c limits.cpu=4 -c limits.memory=8GiB -c migration.stateful=true
incus launch images:debian/13 print01

# snapshot the VM (created above with live migration allowed), then move it to another member
incus snapshot create wms-app01 before-upgrade
incus move wms-app01 --target node2

# take a member out for maintenance and bring it back
incus cluster evacuate node3
incus cluster restore node3

Storage choices in practice

Storage is where most migrations succeed or fail.

Keeping the existing SAN

  • Proxmox VE: present the LUN as shared thick LVM over iSCSI or Fibre Channel. Live migration and HA work. Snapshots there need the 9.0 “volume chain” technology preview; without it, rely on backups rather than snapshots.
  • XCP-ng: iSCSI or HBA SRs are shared LVM, a long established path; snapshots work but are thick, so leave space for snapshot chains during backups.
  • Incus: the lvmcluster driver uses shared LVM with lvmlockd. Workable, but fewer teams run it, so test carefully.

Local disks with replication

  • Proxmox VE with ZFS is a strong small cluster pattern: local NVMe in a ZFS mirror per node, and storage replication of selected VMs to another node every few minutes. Failover loses at most one replication interval of data.
  • XCP-ng protects local SRs across hosts with XO continuous replication, or with XOSTOR.
  • Incus with ZFS or Btrfs gives fast snapshots and copies; moving instances between members copies data unless storage is shared.

Hyperconverged storage

Ceph is fully integrated in Proxmox VE and wants at least three nodes, a fast dedicated network and someone who reads Ceph health. XOSTOR on XCP-ng needs three hosts and has separate support pricing. Incus can consume Ceph or LINSTOR that you run yourself. For a small team, this is rarely the first step.

Clustering, HA and quorum

  • Proxmox VE: Corosync plus pmxcfs, majority quorum, optional QDevice, watchdog fencing; HA groups became node affinity rules in 9.0, and 9.2 added dynamic load balancing and HA disarm for planned network work.
  • XCP-ng: pools with a master, HA on a heartbeat SR, and XO for load balancing and rolling pool updates. Vates lists up to 64 hosts per pool on its Pro and Enterprise plans.
  • Incus: a Raft based database, evacuation for maintenance, optional healing with the caveats above. It expects you to design resilience into storage and the application.

On all three, put cluster traffic on its own network, away from backup traffic that saturates links at night, and test a host failure on purpose before go live, with a stopwatch.

Live migration

  • Proxmox VE live migrates VMs with shared storage, and can also live migrate VMs on local storage by copying disks during migration (slower). Containers are migrated by restart, not live.
  • XCP-ng live migrates within a pool, and storage live migration moves disks of running VMs between SRs or pools; the October 2026 update made storage migration faster.
  • Incus live migrates VMs when migration.stateful is set; containers are normally moved by stopping and restarting them on the target.
  • CPU models matter everywhere. Mixed CPU generations need a common CPU model for VMs, otherwise live migration fails or guests see different features after moving. Proxmox VE 9.2 added a CPU flag view per node and custom CPU models in the UI to help with this.

Backup and restore

Proxmox Backup Server

  • A separate product on its own hardware. Backups are chunked and deduplicated, with optional client side encryption. VM backups are incremental using QEMU dirty bitmaps while the VM runs.
  • Verify jobs re-check stored chunks; sync jobs copy to a second PBS, for example at a DR site. Since 4.2, push sync can encrypt before sending to a less trusted location, and S3 compatible storage is a supported backend. File level restore works from the web UI.
  • Third party products, including Veeam, also support Proxmox VE.

Xen Orchestra backups

  • One of the strongest reasons to pick XCP-ng: full and incremental backups with changed block tracking, encryption, NFS, SMB or S3 targets, mirror backups, replication to another host, pool metadata backups, file level restore and automated restore checks.
  • XO 6.9 added live mount (start a VM straight from its backup); XO 6.10 added live restore in preview and faster mirror backups, up to 1.4 GB/s from 450 MB/s on Vates’ own test bench.
  • According to the XO 6.8 notes, Veeam now officially supports XCP-ng.

Incus

  • incus export and incus import move an instance and its snapshots as a tarball; scheduled snapshots with expiry and copies to another server give simple replication.
  • Since 7.0, an NBD based API with dirty bitmaps lets external tools take incremental VM backups.
  • There is no bundled backup server; you build schedule, retention and the off site copy yourself.

Whatever you choose, do one full restore of a Windows VM and one of a database VM before you call the migration complete.

Coming from VMware

Proxmox VE import wizard

  • Added in 8.2. You add an “ESXi” storage pointing at an ESXi host (through vCenter works but is much slower), pick a VM, map disks and networks, and import.
  • Live import starts the VM on Proxmox while disks copy in the background. The source must still be shut down, and if the import fails, data written since it started is lost.
  • Documented limits: vSAN backed disks and encrypted disks do not import directly, VMs with snapshots import slowly, and vTPM state cannot be migrated, so keep BitLocker recovery keys handy. The ESXi API has a low connection limit, so import one or two VMs at a time.
  • For OVA exports or copied disks, qm disk import attaches a VMDK to a new VM.

Xen Orchestra V2V

  • XO connects to vCenter or ESXi and copies VMs into an XCP-ng pool. Its disk reader, vectura, works with ESXi 6.x again since XO 6.10. Vates reports a steadily better success rate, with corner cases remaining.
  • XO 6.10 disables Viridian by default in the “Other install media” template and asks you to check Windows VMs created from it, V2V imports included.

Incus migrate

  • incus-migrate creates an instance from raw, qcow2, OVA or VMDK images or block devices. For Windows guests from another hypervisor, the docs recommend virt-v2v with virtio-win drivers first, or the VM will not boot. A more manual path.

Preparation on every path

  • Remove VMware Tools, and prepare VirtIO drivers (or the XCP-ng Windows guest tools) in Windows guests before shutdown.
  • Note static IPs; Windows will complain about a duplicate IP on the hidden old adapter.
  • Match firmware type (BIOS or UEFI) and Secure Boot on the target.
  • Keep the VMware VM powered off but intact until the new one has run cleanly for an agreed period.

Operations and day two

  • Updates. Proxmox VE updates through apt, node by node with VMs migrated away. XCP-ng ships monthly and security batches that usually need host reboots; XO’s rolling pool update automates this. Incus updates come with its packages (Debian, the Zabbly repository for Ubuntu, and others) or IncusOS, and the host distribution’s own updates matter just as much.
  • Automation. All three have APIs, Terraform or OpenTofu providers and Ansible support.
  • Monitoring. Proxmox VE pushes metrics to InfluxDB or Graphite, XO can act as an OpenMetrics proxy for Prometheus, and Incus exposes a Prometheus endpoint. Alert first on storage space, quorum and failed backup jobs.
  • Access. Keep management interfaces on a management network, use individual accounts with two factor authentication, and never share root.

Security record

  • Proxmox VE. Proxmox publishes security advisories for its packages. Examples from 2026: CVE-2026-51082 (July), a race in console proxy calls that could let a privileged user hijack another user’s VNC session, fixed in pve-manager 9.1.9 and 8.4.19 and related packages. Public CVE trackers also list further Proxmox advisory batches in late October 2026 for qemu-server, pve-manager and pve-xtermjs, one of them about a crafted link that could run commands as root if opened by a user logged in as root@pam; read the official advisories in the Proxmox forum for exact package versions. The lesson: do not use root@pam for daily work, and keep up with point releases.
  • XCP-ng. Security updates follow Xen Security Advisories (XSAs) and Vates’ own VSA numbers. The 13 October 2026 batch fixed several Xen issues, including a grant table race that could let a guest gain host privileges (XSA-517) and an out of bounds access in tapdisk that could give a malicious guest code execution in dom0 (XSA-521). On 22 October a further batch removed compromised eMudhra intermediate certificates from the trust store, which is directly relevant to Indian users. XO had its own advisories in 2026, including a broken access control issue in XO 5 fixed with 6.10.
  • Incus. Nine CVEs from a security audit were fixed in 7.0, all moderate or low. Containers share the host kernel, so for untrusted tenants use VMs or unprivileged containers with care, and keep the host kernel patched.
  • Common ground. A hypervisor bug can affect every VM on a host, so treat host patching as more urgent than guest patching, and subscribe to each project’s advisory feed.

Licences and commercial models

  • Proxmox VE: AGPLv3. Subscriptions are per occupied CPU socket per year, with list prices on the Proxmox site of 120 euro for Community (access to the enterprise repository, no support tickets), 370 euro for Basic, 550 euro for Standard and 1,100 euro for Premium. All nodes in a cluster must use the same level. There are no feature editions; every feature works without a subscription.
  • XCP-ng and Xen Orchestra: XCP-ng is free; Xen is GPLv2, XAPI LGPL 2.1, XO AGPLv3. Vates sells the “Vates VMS” bundle with support per host per year (the Pro plan is listed at 1,000 per host per year with a minimum of three hosts) or as small Essential bundles for up to three hosts, plus separate XOSTOR support. The XOA appliance has edition dependent features; building XO from source gives all features without support.
  • Incus: Apache 2.0, no paid edition. Commercial support from Zabbly. Canonical’s LXD, the project Incus forked from, moved to AGPLv3 with a contributor licence agreement in December 2023, after which the two projects stopped sharing code.

Check current prices and currency for your region on the vendor sites before you build a budget; they change.

Side by side

  • Model and fit. Proxmox VE is an all in one distribution for teams who want one UI for everything. XCP-ng with XO is closest to the vSphere and vCenter mental model and suits Windows heavy shops with strong backup habits. Incus is API first and suits Linux heavy teams that automate everything.
  • Storage and HA. Proxmox VE has the widest built-in storage support and mature HA with fencing. XCP-ng has the classic SR model, XOSTOR and heartbeat SR based HA. Incus has many storage drivers, but HA is more your design than the platform’s.
  • Backup and import. Proxmox Backup Server is excellent and free, with the ESXi wizard for imports. XO has the most complete built-in backup engine and its own V2V tool. Incus gives you export, snapshots and the NBD API, and a manual import path.
  • Lifecycle and governance. Proxmox is one company in Vienna with a Debian aligned cycle. XCP-ng is led by Vates in France, with 8.3 LTS until November 2028 on an old dom0 base. Incus is a community project with five year LTS releases and a small, very active maintainer team.
  • Performance. All three run business VMs at close to bare metal speed for CPU bound work. Differences come from storage paths, drivers and tuning, not the hypervisor brand, and vendor figures quoted in this post are each vendor’s own runs. Measure your own ERP batch job and database restore before and after migration.

A worked plan for Indore

A deliberately boring plan for Harshal’s team.

  1. Inventory everything. List all 45 VMs with OS, firmware type, disks, sizes, network, whether they use vTPM or encryption, owner, allowed downtime and migration order. Mark which ones can be rebuilt fresh instead of imported.
  2. Decide the platform after a two week pilot. Install Proxmox VE 9.2 on one spare host and XCP-ng 8.3 with XOA on another. Import the same three VMs (one Linux, one Windows file server, one SQL test VM) to both, back them up and restore them. Choose the one the team found easier to operate, not the one that felt faster.
  3. For the rest of this plan, assume Proxmox VE. Buy at least Community subscriptions so production uses the enterprise repository, and consider Basic for support tickets. Do not run production on the no-subscription repository by default.
  4. Build the cluster properly. Three hosts, a dedicated cluster network on its own switch ports, a second Corosync link on another network, management on a separate VLAN, and individual admin accounts with two factor authentication. Do not use root@pam for daily work.
  5. Keep the SAN for now. Present the iSCSI LUN as shared LVM for HA VMs. Put new, fast local NVMe in each host as a ZFS mirror for VMs that can use replication instead. Plan the SAN replacement as a separate project later.
  6. Stand up Proxmox Backup Server first. On separate hardware in Indore, with a second PBS at Dewas receiving an encrypted push sync. Keep the weekly offline copy, but on a schedule, not on a person’s goodwill.
  7. Migrate in waves. Wave one: test VMs and the monitoring VM. Wave two: Linux apps including the warehouse system, with the PostgreSQL database also protected by its own backup tool. Wave three: Windows servers, one domain controller at a time. Wave four: the ERP SQL Server VM in a planned weekend window, after a rehearsal with a copy.
  8. For each VM: remove VMware Tools, install VirtIO drivers on Windows, note IPs, shut down, import with the ESXi wizard (live import only for VMs where a failed import is acceptable), boot, check, run a backup, and keep the VMware copy powered off for two weeks.
  9. Test failure on purpose. Pull the power on one host during a quiet hour and time how long HA takes to restart VMs. Restore one Windows VM and the ERP database from PBS to an isolated network.
  10. Write the runbook. Monthly update procedure, how to add a node, how to replace a disk, how to restore, and whom to call. Subscribe to Proxmox advisories.
  11. Pilot Incus for Linux services next year. Small internal web apps and the print server may be better as system containers. Try them in Incus or in Proxmox’s own LXC containers before deciding.
  12. Retire VMware cleanly. Only after all waves, backups and restore tests pass, and only after the backup vendor’s old VMware jobs have been replaced and their retention handled.

When not to adopt each

  • Proxmox VE: not if your team refuses to learn basic Debian and Linux administration, and not in a two node setup without a QDevice.
  • XCP-ng: not if you need a modern dom0 base or the newest hardware support today; 8.3 sits on CentOS 7 userland and a 4.19 kernel until XCP-ng 9.0 is ready. Also think twice if you will not run Xen Orchestra, because much of the value lives there.
  • Incus: not as a drop-in vCenter replacement for a Windows heavy shop that expects a full GUI, automatic HA and a bundled backup server.
  • Any of them: not as a rushed weekend migration driven only by a renewal date. A late renewal is cheaper than a lost ERP database.

A short history

  • Xen came out of the University of Cambridge and was first released in 2003. Citrix bought XenSource in 2007 and built XenServer on it.
  • Proxmox VE was first released in 2008 by Proxmox Server Solutions in Vienna, combining KVM and OpenVZ containers; it switched from OpenVZ to LXC with version 4.0 in 2015.
  • XCP-ng started in 2018, after Citrix moved features out of the free XenServer edition, and its first release, 7.4, came out in March 2018. Vates, the company behind Xen Orchestra, leads the project.
  • LXD was announced by Canonical in 2014 as a manager on top of LXC. In July 2023 Canonical took LXD out of the Linux Containers project. In August 2023 Aleksa Sarai forked it as Incus, which Linux Containers adopted with the original LXD team as maintainers; Incus 0.1 came out in October 2023, 6.0 LTS in April 2024 and 7.0 LTS in May 2026.
  • 2023 to 2026: Broadcom’s acquisition of VMware and its licence changes pushed many organisations to evaluate these platforms at the same time.

Decision guide

You are a small or medium team leaving vSphere with mixed Windows and Linux VMs

Proxmox VE with Proxmox Backup Server. Three nodes, a proper cluster network, the enterprise repository, and the ESXi import wizard.

Your team thinks in vCenter terms and values built-in backup above everything

XCP-ng 8.3 LTS with Xen Orchestra (XOA with a Vates subscription, or built from source if you accept no support). Plan for the move to XCP-ng 9 before November 2028.

Your workloads are mostly Linux and your team automates everything

Incus 7.0 LTS, with system containers for Linux services and VMs where needed, managed by OpenTofu or Ansible, and a scripted backup on top of snapshots and export or the NBD API.

You already run Kubernetes seriously and have a few VMs left

Look at KubeVirt or Harvester, and keep a small Proxmox or XCP-ng cluster for the stubborn Windows VMs if needed.

You have two servers and no budget for a third

Proxmox VE with a QDevice on a small machine, ZFS replication between the two nodes, and honest expectations about failover.

Checklist

  • Written inventory with OS, firmware, disks, downtime allowance and owner per VM.
  • Pilot on the chosen platform with at least one Windows and one database VM, including a restore.
  • At least three votes for quorum (three nodes, or two plus QDevice).
  • A dedicated cluster network, separate from backup and storage traffic.
  • Production on the supported, tested update channel.
  • A backup server or engine on separate hardware, with an off site copy and encryption.
  • A scheduled restore test, owned by a named person.
  • VirtIO or guest tools prepared for Windows guests; BitLocker recovery keys saved.
  • Individual admin accounts with two factor authentication; no daily use of root.
  • Advisory subscriptions for the platform and its management tool, and a monthly patch window.
  • A rollback plan per VM: the VMware copy kept powered off for an agreed period.
  • For Proxmox VE 8: an upgrade to 9 scheduled now, since 8 is end of life.

Common mistakes

  • Two node clusters without a third vote. One node reboots, the other loses quorum and stops accepting changes. Add a QDevice or a third node.
  • Cluster traffic on the backup network. Nightly backups saturate the link, Corosync misses heartbeats, and HA fences a healthy node.
  • Running production on the free test or no-subscription stream without a plan. It works until an update surprises you. Know what each repository promises.
  • Importing Windows VMs without drivers. The VM boots to a blue screen because the disk controller changed. Prepare drivers first.
  • Treating containers as VMs for untrusted workloads. System containers share the host kernel. Use VMs for anything you do not trust.
  • Forgetting the management plane. XOA, Proxmox Datacenter Manager or the Incus API need their own backups, updates and access control.
  • Calling the migration done before a full restore test. Backup jobs that “succeed” prove very little until a restore boots.

About a hands-on drill

We did not run a hands-on drill for this post. Testing a hypervisor properly needs bare metal hosts or nested virtualization, shared storage and several machines, which our small loopback-only test box cannot provide safely. Every statement about Proxmox VE, XCP-ng, Xen Orchestra and Incus here comes from their official release notes, documentation, licence files, pricing pages and security advisories, listed below, not from our own measurements. If you repeat this comparison, the most useful test is simple: import the same three VMs into each candidate, back them up, restore them on another host, and time a host failure.

Unlearn, re-learn

  • Unlearn “pick the fastest hypervisor”. Re-learn that quorum, storage, backup and patching decide whether the platform survives, and all three hypervisors are fast enough.
  • Unlearn “open source means free”. Re-learn that you still pay, in subscriptions, in staff time, or in risk, and choose which on purpose.
  • Unlearn “the import wizard does the migration”. Re-learn that drivers, IPs, firmware, licences and a rollback plan are the migration, and the wizard only copies disks.
  • Unlearn “containers or VMs”. Re-learn that Linux services may be happier as system containers while Windows and untrusted workloads stay in VMs.
  • Practise a restore and a host failure every quarter, and apply the smallest platform your team can run well for five years.

Sources

XCP-ng and Xen Orchestra

Incus

VMware context and others

comments powered by Disqus

Releted Posts

Infrastructure monitoring in 2026: revisit Zabbix, Checkmk and Netdata before you add another host to your monitoring

In most Indian companies, monitoring starts with a person, not a tool. Somebody in the IT team logs in to the file server every morning, checks the disk, looks at the UPS panel, pings the branch router, and goes back to work.

Read more

HTTP caching in 2026: revisit Varnish and Vinyl Cache, Apache Traffic Server and NGINX before you put another cache in front of your app

Most teams add an HTTP cache on a bad day. The home page is slow during a traffic spike, the database is at 100% CPU, and somebody says “let us just put Varnish in front”.

Read more

Infrastructure access in 2026: revisit Teleport, Boundary and Warpgate before you hand out another SSH key

Every engineering team has an access story it does not like to tell. A new developer joins, and someone appends her public key to authorized_keys on fourteen servers by hand.

Read more