Convert XVA to VMDK

A VMware product such as Workstation, Fusion, or ESXi cannot normally open an XVA export directly, so migration from XenServer or XCP-ng requires converting the virtual disks. The practical route is to restore or extract the XVA, export each disk as VHD, and convert the VHD files to VMDK.

What the XVA format is

XVA is a virtual-machine export container produced by Citrix XenServer, Citrix Hypervisor, and XCP-ng. It is a tar-based archive containing VM metadata, commonly including ova.xml, and disk data represented by XenServer VDI blocks or archive members.

Administrators use XVA files to move VMs between XenServer or XCP-ng environments, create offline exports, and provide VM backups. An XVA is not itself a VMware virtual disk, and renaming its extension to .vmdk does not convert it.

What the VMDK format is

VMDK is VMware's virtual-disk format. VMware Workstation, Fusion, and ESXi can attach VMDK files to new or existing virtual machines; other hypervisors also support many VMDK variants.

VMDK can be sparse, expanding as data is written, or preallocated, reserving most or all of its virtual capacity in advance. The conversion changes the disk container and does not convert Xen-specific VM hardware, snapshots, network settings, or guest drivers.

How to convert the disks

Restore the XVA and export its VDI

This is the most reliable method when a XenServer or XCP-ng host is available.

1. Import the XVA into XenServer, Citrix Hypervisor, or XCP-ng with XenCenter, Xen Orchestra, or the platform's documented import command.
2. Start the imported VM only if necessary to verify it, then shut it down. Do not export or convert a disk while the guest is writing to it.
3. Identify every virtual disk attached to the VM, including data disks. Export each VDI as a VHD using the management client or the host command line. A XenServer-style command is:

xe vdi-export uuid=<VDI_UUID> filename=disk.vhd format=vhd

Use the equivalent VDI export operation in XCP-ng if the command syntax differs. Preserve the original disk order and record which VHD is the boot disk.

Convert VHD to VMDK with qemu-img

Install QEMU on Linux or Windows and inspect each exported disk before conversion:

qemu-img info disk.vhd

If the output identifies the source as a VHD, convert it to the default sparse VMDK:

qemu-img convert -p -f vpc -O vmdk disk.vhd disk.vmdk

If qemu-img info reports a different source type, use that reported type instead of vpc. For a preallocated monolithic VMware disk, use:

qemu-img convert -p -f vpc -O vmdk -o subformat=monolithicFlat disk.vhd disk.vmdk

Check the destination's free space before creating a preallocated disk. Repeat the conversion for every VHD, then attach the resulting VMDKs to a new VMware VM in the same order as the original Xen VM.

Extract an XVA without a Xen host

An XVA is a tar archive, so its metadata and members can be inspected locally:

mkdir xva-extracted
tar -xf vm.xva -C xva-extracted
find xva-extracted -maxdepth 4 -type f

The extracted files are not necessarily standalone VHDs. Many XVA exports contain XenServer disk chunks that must be reassembled into a disk image. If the export includes a complete VHD, verify it with qemu-img info and convert it as shown above. If it contains chunks, use the xva-img utility supplied for the relevant XenServer or XCP-ng version, following that version's documented disk-extraction command, or import the XVA into a Xen host and export the VDI there.

Do not concatenate archive members manually; XVA metadata and chunk layout are not a generic sequence of VHD files, and manual concatenation can produce a corrupt disk.

Windows desktop software

After obtaining a complete VHD, StarWind V2V Converter can convert it on Windows. Select the local VHD as the source, choose VMware VMDK as the destination, and select a growable or preallocated layout. StarWind generally does not convert the XVA archive itself, so extraction or Xen-side restoration is still required.

qemu-img is preferable for scripted or repeatable conversions. XenConvert is an old Xen migration utility and should not be treated as a current direct XVA-to-VMDK converter.

Compatibility and quality checks

• The disk conversion normally preserves partitions, filesystems, and guest files, but not XenServer VM metadata, pool membership, snapshots, virtual NIC definitions, or Xen-specific tools.
• Match the original guest's BIOS or UEFI mode and choose a VMware storage controller compatible with the installed operating system. A controller or firmware mismatch can prevent booting.
• Windows may detect new virtual hardware, require reactivation, or need storage-driver changes. Linux may require an initramfs containing the VMware storage driver.
• Remove or disable Xen guest tools if they cause driver or service errors, then install VMware Tools after the guest boots. Expect the virtual network adapter and MAC address to change.
• Keep the original XVA until the converted VM boots and its filesystems pass checks. Mount or boot-test every converted disk and verify application data before deleting the source.
• A sparse VMDK can be much smaller than its virtual capacity, while a preallocated VMDK can approach the full provisioned size. Neither size indicates data loss by itself.
• No mainstream online conversion service reliably accepts XenServer or XCP-ng XVA archives and reconstructs their VDI data. Uploading an XVA would also expose complete disks, credentials, personal data, and possibly private keys, so use local tools for production or confidential exports.