Xen Orchestra 5.110 introduced a new migration backend for moving virtual machines from VMware to XCP-ng (V2V). It replaces the old NFS-based method with nbdkit and VMware's VDDK libraries, delivering better performance and reliability.
The whole process is driven from Xen Orchestra, in Import → VM → From VMware. XO connects to your vCenter or ESXi host, reads the VM disks directly, and imports them into an XCP-ng storage repository:
XO reads the VM disks from ESXi through nbdkit and the VDDK libraries, and imports them into an XCP-ng pool. The source VM keeps running during most of the transferVMwareXCP-ngXO
This guide walks you through the entire migration process:
Preparing your Xen Orchestra environment
Preparing your VMware environment
Running a test migration
Executing the final cutover
You will also find troubleshooting advice and best practices to maximize speed and minimize downtime.
note
The V2V import is currently available in the XO 5 interface. The new XO 6 web UI does not expose it yet: even if you use XO 6 daily, switch to the XO 5 interface for the migration itself.
The new backend only reads allocated blocks, which accelerates transfers, and snapshots have minimal impact on performance. There is no longer any need for temporary NFS storage or remote VSAN targets. Very large disks are handled natively: disks bigger than the 2 TB VHD limit are automatically imported in the QCOW2 format, provided the destination storage repository supports it.
The interface has also seen significant improvements: a progress bar is now visible from the start of the migration, speed metrics are recorded in the VDI, and snapshots are created at each step. This allows you to pause and resume the process safely without creating multiple VMs. The import is cancellable, and the connection settings are remembered by your browser between sessions.
Additionally, UEFI VMs are no longer forced into Secure Boot mode, which resolves previous boot issues.
Recent releases keep improving the workflow: since XO 6.6, a CD-ROM drive present on the source is recreated on the destination VM, and a two-step transfer (a first warm pass followed by a final run) tells you upfront whether the next run will be a full or a delta transfer.
Performance gains can be significant, though results depend on the environment:
In the best case, when using VMs with many snapshots or mostly empty disks, migrations can be up to 100 times faster. In our high-performance lab, we measured around 150 MB/s per disk and up to 500 MB/s total, which means an infrastructure with 10 TB of data could be migrated in a single day, with less than five minutes of downtime per VM.
In less favorable situations, such as a fully allocated disk with no snapshots and a powered-off VM, improvements are smaller, mainly due to compression between XO and ESXi. In general, the limiting factor is the import speed on the XCP-ng side, which scales well until the storage is saturated. Most of the transfer occurs while the VM is running, so production data remains safe.
Make sure your Xen Orchestra instance is up to date. The import page includes an automatic check that verifies the installed versions of nbdkit, the VDDK plugin and nbdinfo, and highlights errors and warnings before the migration. Errors must be resolved, and warnings should be addressed when possible.
zoomed detailThe prerequisite check on the import page, listing nbdkit, the VDDK plugin and nbdinfo with their status
This procedure requires an active Internet connection and has only been tested on Debian 12 and 13.
In the future, we plan to include the latest libraries directly in XOA.
To install nbdinfo on Debian:
Go to the Import → VM → From VMware section.
Click the button called install nbdinfo (debian based system):
zoomed detailThe install nbdinfo (debian based system) button on the From VMware import page
This starts the install.
Keep an eye on the current page to make sure the install goes as planned.
The install nbdinfo button updates to show the installation progress, and the page displays any warnings in real time as they appear:
zoomed detailThe import page while the nbdinfo installation task is running, with warnings shown in real time
Additionally, the Tasks screen shows the nbdinfo install task, with its name, start date, start time and status indicator:
zoomed detailThe Tasks screen showing the running nbdinfo install task with its status indicator
The task is removed from the list upon completion.
Once the installation finishes, the nbdinfo install screen updates automatically. It lets you know if everything was completed successfully and flags any warnings that came up during the process:
zoomed detailThe import page after a completed nbdinfo installation, with the final status and warnings
tip
nbdkit and the nbdkit-plugin-vddk are installed using the same approach.
XO must be able to connect to the vSphere or ESXi host through the port running the web UI (default port: 443) and the VDDK data port (default port: 902). At the time of writing, there is no way to select one network or another, so if possible, keep a single network path from XO to VMware.
Here is the "surefire method" to prepare your VMware environment.
It involves a lot of manual steps, but it lets you detect and fix issues without impacting production.
tip
There is also a "fire-and-forget" approach: launch the migration with the Stop source option enabled, then start the VM once the migration is complete.
This method is only recommended for non-critical VMs, and only after the first few migrations have gone smoothly.
Once the prerequisites are met, follow these steps to prepare the source VM:
Understanding the warm migration mechanism helps you follow the progress:
If the source VM is running and has no snapshot, XO automatically takes one, named [V2V] migration to XCP-ng.
XO creates the destination VM (its name ends with importing... while the transfer runs) and imports the read-only snapshot chain while the source VM keeps running in production.
A snapshot of the destination VM is taken after this first pass, so the process can be resumed safely without creating duplicate VMs.
If the Stop source option is enabled, XO then powers off the source VM in VMware, transfers only the final delta (the blocks written since the snapshot), and takes a final complete import from V2V snapshot.
As long as the import is partial (the source VM is still live), XO blocks the destination VM from starting normally, to prevent both copies from running at once.
Start the V2V migration in Xen Orchestra, without enabling the Stop source option.
This will transfer the VM data up to the snapshot named vm without tools.
tip
You can safely close your browser while the migration runs.
Monitor the migration progress using one of these methods:
Check the VM status in Xen Orchestra (its name should show importing...).
Start the migrated VM copy on your XCP-ng environment. Since the source VM is still running, XO protects the partially synced copy: confirm the force start when prompted.
tip
Use an isolated network to avoid IP conflicts.
The VM state might be slightly inconsistent since memory and cache data aren't fully synced.
Check the following during testing:
The VM boots up without issues.
Network connectivity is working properly.
Xen Tools installs and runs correctly.
Document any fixes or adjustments required to stabilize the VM.
Once you have finished your checks and taken notes, delete the test VM. This will free up resources and prevent any confusion before the final migration.
Start the V2V migration in Xen Orchestra with the Stop source option enabled.
This ensures the final sync happens while the VM is powered off, and prevents any inconsistencies.
Apply any fixes or tweaks you identified during the test migration, and install the Xen guest tools if you have not already.
The migrated VM includes the snapshots taken during the import, which you can use for rollback. If needed, create additional snapshots before making further changes.
If you encounter problems during migration, try these steps to diagnose and resolve them:
Check VMware logs
Look for disk access errors in the VMware logs. These may point to issues with the source storage or VM configuration.
Update software versions
Ensure nbdkit and nbdinfo are up to date. Older versions can cause compatibility issues with the VDDK plugin. The prerequisite check on the import page flags outdated versions.
Remove active snapshots
Make sure no active snapshots remain on the source VM. Snapshots can disrupt migration consistency.
Verify destination storage
Confirm the XCP-ng storage repository has enough free space for the migrated VM.
Test network connectivity
Ensure stable network connectivity between the VMware environment, Xen Orchestra, and XCP-ng hosts.
Retry with cold migration
If warm migration fails, power off the VM, remove all snapshots, and try again.
When migrating a VM from VMware, the system may fail to boot if the required Xen drivers are not pre-installed.
To avoid this, use the dracut utility on the source VM prior to migration. For the specific driver injection procedure, refer to the XCP-ng migration guide.
Use fast SSD storage for both the XCP-ng storage repository and Xen Orchestra's working directory.
This speeds up the initial migration and enables smoother live migrations afterward.
