This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
By:
XVA is XenServer’s native VM export format. If you’re moving to VMware, ESXi won’t recognize it — you’ll need to convert it to VMDK first. This guide walks through four ways to do that, plus how to fix the boot and driver issues that often come up after migration.
An XVA file is the standard export format for Citrix XenServer and XCP-ng. It packages the VM’s VHD disks and an XML configuration file into a single tar archive.
VMDK is VMware’s virtual disk format. ESXi and vSphere require it to run virtual machines. The VMX file works alongside it as the configuration file that defines the VM’s hardware settings.
Because XVA is a packaged archive and VMDK is a flat disk image, VMware cannot mount or boot an XVA file directly. Converting the disk format is the only way to get a XenServer VM running on ESXi.
This conversion comes up most often during platform migrations, data center consolidations, and disaster recovery setups where the two sites run different hypervisors.
Successful migrations depend more on how the source VM is prepared than on the conversion tool itself. Skipping these steps often results in non-bootable systems or “Inaccessible Boot Device” errors.
The manual method for Linux users involves breaking open the XVA archive and rebuilding the disk image from its component parts. This approach gives you the most control and works well for XCP-ng or standalone XenServer hosts.
Start on the XenServer host and work through to a raw disk image before touching anything on the VMware side.
Step 1: Export the VM from XenServer: Run the following command directly on the XenServer or XCP-ng host to export the VM as an .xva file.
sudo yum install qemu-img
Step 2: Extract the XVA archive: XVA files are tar archives containing 1MB disk chunks. Extract the contents into a working directory.
mkdir xva_out && tar -xf vm.xva -C xva_out
Step 3: Rebuild the raw disk: Use xva-img to reassemble the extracted chunks into a single raw disk image. The chunks are stored in a subdirectory named after the disk reference, such as Ref:1.
xva-img -p disk-export xva_out/Ref\:1/ vm.raw
Step 4: Verify the raw image: Confirm the output file was created correctly before proceeding.
qemu-img info vm.raw
Step 5: Convert the raw disk to VMDK: Use qemu-img to produce a VMDK file from the raw image.
qemu-img convert -f raw -O vmdk vm.raw output.vmdk
VMDK ready, the remaining steps move to the VMware environment.
Step 6: Upload to VMware: Transfer the .vmdk file to your ESXi datastore using the vSphere Client or SCP. Then create a new VM and select Use an existing virtual disk to attach it.
XenConvert is a legacy Citrix utility designed for moving virtual appliances between formats. While it is no longer actively updated, it remains an option for Windows-based admins who prefer a graphical interface over the command line.
XenConvert version 2.3.1 or 2.3.2 is required for this workflow. Versions 2.4 and newer removed XVA-to-OVF conversion support, making them unsuitable for this migration path.
Begin by exporting the VM from XenServer and running it through XenConvert to produce a usable disk file.
xe vm-export vm=<VM_NAME> filename=vm.xva
Before importing the disk, the descriptor file needs one manual edit to prevent a boot failure on VMware.
qemu-img convert -f vpc -O vmdk input.vhd output.vmdkddb.adapterType = "lsilogic"With the descriptor corrected, the disk is ready to be uploaded and attached to a new VM.
Using the OVA (Open Virtualization Appliance) format is often the most efficient way to move a VM between hypervisors. Since both Citrix and VMware support the OVF standard, this method requires no separate V2V conversion tooling.
The first step is generating the OVA file from your existing XenServer or XCP-ng environment.
Once the OVA file is ready, the rest of the process is handled entirely within vSphere.
This method differs from manual exports because it converts a running VM directly over the network, with no XVA export or disk file handling required. It follows a similar approach to VMware P2V migration, where Converter manages the transfer and format translation automatically.
Before starting the conversion job, confirm that both of the following conditions are met.
This method requires stable network connectivity between the XenServer host and the target ESXi host or vCenter. VMware vCenter Converter Standalone also needs to be installed on a Windows machine that can reach both environments.
With the prerequisites in place, open Converter and follow these steps to start the migration.
Once the migration completes, install VMware Tools on the guest OS. If XenServer Tools were not removed beforehand, uninstall them first before installing VMware Tools.
Even with a clean conversion, a migrated VM may fail to boot or perform poorly. Most issues stem from differences in how XenServer and VMware handle storage controllers and device drivers.
This is typically caused by a SCSI controller mismatch. Start by checking the .vmdk descriptor file — open the smaller of the two .vmdk files in a text editor and confirm the adapter type is set correctly:
ddb.adapterType = "lsilogic"
If the descriptor is correct but the VM still fails to boot, change the disk controller type in the VM settings to LSI Logic SAS or LSI Logic Parallel and retry.
The guest OS may not detect a network adapter after the first boot because VMware uses a different virtual NIC (VMXNET3) than XenServer. Install VMware Tools to provide the correct network drivers.
If the VM boots but runs slowly, check whether XenServer PV drivers or Citrix components are still installed. These drivers attempt to communicate with the Xen hypervisor, which no longer exists in the new environment, causing unnecessary system overhead. Uninstall all Xen and Citrix components and reboot.
The methods covered in this guide work well for one-off migrations, but they require significant manual effort — exporting XVA files, handling disk chunks, editing descriptor files, and troubleshooting boot failures along the way. For teams moving multiple VMs or running migrations in production environments where downtime is not an option, a dedicated migration platform is a more practical approach.
i2Migration is a unified migration platform built for cross-platform workload transfers across physical, virtual, and cloud environments. It handles the kind of heterogeneous virtualization migrations covered in this article — including V2V scenarios between different hypervisor platforms — without requiring manual disk conversion or file handling.
For teams that also need ongoing data protection after the migration, i2Availability provides real-time replication and automated failover between environments, making it a natural complement once your VMs are running on VMware.
Q1: Can I convert XVA to VMDK without Linux?
Yes. The Windows-based XenConvert tool (version 2.3.1 or 2.3.2) handles the conversion without any command-line work. Alternatively, exporting the VM from XenCenter as an OVA file is generally the simpler option — it imports directly into vSphere without requiring any disk manipulation.
Q2: Does XVA contain multiple disks? How to handle them?
An XVA file can contain multiple virtual disks. When you extract the archive with tar, each disk is stored in its own subdirectory — Ref:1, Ref:2, and so on. Run xva-img on each directory separately to produce individual raw images, then convert each one to VMDK before attaching them to the new VM in vSphere.
Q3: Can I convert back from VMDK to XVA?
Yes, though the process is not a single-step reverse. Export the VMware VM as an OVF or OVA, then use the Import wizard in XenCenter to bring it back into XenServer. The import handles the disk format conversion, but plan to remove VMware Tools and reinstall XenServer Tools on the guest OS afterward.
Q4: Can I just use OVA instead of converting XVA manually?
Yes, and for most environments it is the recommended approach. OVA is an industry-standard format supported by both XenServer and VMware, so it eliminates the need for manual disk rebuilding or descriptor file editing. The main limitation is that older XenServer versions may not support OVA export — in those cases, the manual xva-img method is the fallback.
Converting XVA to VMDK is rarely a single-step process. Depending on your environment and available tools, the right method varies — the Linux command-line approach gives you the most control, XenConvert and the OVA method work well for Windows-based workflows, and vCenter Converter is the best option when you need to migrate a running VM without any downtime.
Whichever method you use, the preparation steps matter as much as the conversion itself. Removing XenServer Tools before export and correcting the disk adapter type afterward are the two steps most likely to determine whether your VM boots cleanly on the first try.
For teams handling larger-scale or production migrations, Info2soft’s i2Migration removes most of this manual overhead — handling cross-platform V2V transfers, driver injection, and validation automatically so you can focus on the migration outcome rather than the tooling.
