Migrating from Xen / XenServer: conversion paths

Xen in the wild

Xen is older than KVM and still runs significant workloads at telcos, hosting providers, and research institutions. Two flavours you’ll encounter:

• Xen / Xen Project (open source) — bare metal hypervisor, uses xl toolstack
• Citrix XenServer / XCP-ng — enterprise fork, uses xe toolstack and supports Windows guests with the Citrix PV drivers

Both produce disk images in a few formats: raw, VHD, VHDX, and (rarely) qcow2. The migration path is similar in each case but the extraction step differs.

Disk format cheat sheet

Run qemu-img info disk.img first. It reports the format and lets you skip the -f flag guesswork.

Cold migration: the safe path

For Xen VMs, the cold path is straightforward: shut down the VM, locate the disk image on a Storage Repository, copy it off, convert it.

Step 1: Find the disk

# On XenServer / XCP-ng via xe CLI
xe vdi-list name-label="vm01 disk" params=all

# This returns the uuid, sr-uuid (storage repository), and virtual-size.
# Find the underlying file path on the SR:
ls -lh /run/sr-mount/<sr-uuid>/<vdi-uuid>.vhd

# On Xen Project with xl toolstack, disks live wherever the config says
cat /etc/xen/vm01.cfg | grep disk
# Typically: disk = ['tap:aio:/var/lib/xen/images/vm01.img,xvda1,w']

Step 2: Copy the disk off

# For XCP-ng, use xe vdi-export (streamed, faster than scp for sparse files)
xe vdi-export uuid=<vdi-uuid> filename=/tmp/vm01.vhd format=vhd

# Or raw copy if you prefer
scp root@xenhost:/run/sr-mount/<sr-uuid>/<vdi-uuid>.vhd ./

# For raw Xen Project images
scp root@xenhost:/var/lib/xen/images/vm01.img ./

Step 3: Convert

# VHD to qcow2 (most common)
qemu-img convert -f vpc -O qcow2 vm01.vhd vm-101-disk-0.qcow2

# raw to qcow2 (Xen Project with file: backend)
qemu-img convert -f raw -O qcow2 vm01.img vm-101-disk-0.qcow2

# raw to raw for LVM-thin (zero-copy on the destination)
qemu-img convert -f raw -O raw vm01.img vm-101-disk-0.raw

Step 4: Import into Proxmox

qm create 101 --name "vm01" --memory 4096 --cores 4 --net0 virtio,bridge=vmbr0
qm importdisk 101 vm-101-disk-0.qcow2 local-lvm -format qcow2
qm set 101 --scsi0 local-lvm:vm-101-disk-0 --boot order=scsi0
qm set 101 --bios ovmf --efidisk0 local-lvm:1,efitype=4m
qm start 101

Linux guest quirks

Linux guests installed on Xen often use:

• xvd device names (/dev/xvda1) instead of /dev/sda1. Modern kernels have xvd drivers; the kernel should still find the root filesystem via initramfs.
• xenblk as the disk driver. Remove it from initramfs if converting fully to virtio, otherwise you’ll have a stale dependency.
• xenfs and xen-netfront kernel modules. Harmless on Proxmox; you can leave them.

# Inside the Linux guest, before or after migration:
# Regenerate initramfs so it has virtio_blk and virtio_net
dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

# Verify the boot cmdline points to the right root device
# Edit /etc/default/grub and /etc/fstab if they reference /dev/xvd*

Windows guest quirks

Windows guests on XenServer / XCP-ng used Xen PV drivers (citrix xen drivers). These do not work on KVM. You must uninstall them before migration or the VM will BSOD.

Alternative: boot the converted VM with IDE emulation (--scsihw ide), uninstall the Xen drivers, shut down, switch to virtio. This is slow but reliable.

Network mapping

Xen bridges (xenbr0) correspond to Proxmox bridges (vmbr0). VLAN tagging at the bridge level is identical. The VM-side network configuration (IPs, routes) is in the guest OS and migrates as-is.

When to use virt-v2v

virt-v2v supports Xen guests too, but coverage is patchy — it works best for Linux guests with a single disk and standard paravirt drivers. For complex Xen VMs, the manual cold path is more reliable and gives you control over the quirks.

# virt-v2v for XenServer
virt-v2v -i xen ssh://root@xenhost/

# Or for a Xen Project libvirt-managed VM
virt-v2v -i libvirt xen:///vm01

Validation

Same checklist as VMware:

• Boots to login prompt
• Network connectivity (xvd → virtio transition handled by kernel)
• Services start
• Backup runs successfully
• Live migration works

For Windows guests specifically:

• Device Manager shows no “unknown device” entries
• Disk performance is acceptable (if not, switch to virtio-scsi)
• Windows activation still valid

Key takeaways

• Xen disks are usually VHD (XenServer) or raw (Xen Project) — both convert with qemu-img
• Linux guests migrate cleanly; kernel handles xvd → virtio automatically
• Windows guests require Xen PV driver removal, or they’ll BSOD
• Cold migration is safer than virt-v2v for Xen — the manual path handles more edge cases

Knowledge check