How to migrate a VMware VM to KVM with XReplicator

XReplicator can provide a VMware exit path without reading VM disks through VMware APIs. The agent runs inside the protected guest, sends block-level backups to an XReplicator repository, and lets an authorized operator export a selected restore point as a raw image.

The raw image is the portable handoff. QEMU can use raw images directly, qemu-img can convert them to QCOW2, and virt-v2v can adapt supported Windows and Linux guests for KVM. This is a planned migration workflow, not a live hypervisor conversion: the operator still needs to identify the VM's disks, preserve their order, recreate the VM configuration, and prove that the recovered workload boots correctly.

Before you begin

Use a non-production VM for the first migration. Confirm that the target KVM host has enough storage for the exported raw images and converted disks, and keep the original exports unchanged until the migration is accepted.

Record these source details before cutover:

• Operating system and CPU architecture.
• Whether the VM boots with BIOS or UEFI, including Secure Boot requirements.
• CPU, memory, network, VLAN, IP, DNS, and MAC-address dependencies.
• Every virtual disk, its capacity, and whether it contains the operating system or application data.
• Disk encryption requirements and the location of recovery keys.
• Applications or databases that require a coordinated shutdown or application-consistent backup.

For Linux, these commands provide a useful disk, mount, and firmware inventory:

• lsblk -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS
• findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
• test -d /sys/firmware/efi && echo UEFI || echo BIOS

For Windows, review the complete disk and partition layout rather than relying only on drive letters:

• Get-Disk | Format-Table Number, FriendlyName, PartitionStyle, OperationalStatus, Size
• Get-Partition | Sort-Object DiskNumber, PartitionNumber

The operating-system export must represent the complete boot disk, including its partition table and required EFI or system partitions. A raw image of only C: or only the root filesystem is not automatically a bootable VM disk. XReplicator's current Windows drive-letter backups are volume images, so do not treat a C: export as a complete boot disk. Use this workflow only when the selected restore point represents the complete source disk, or provide the missing boot partitions through a separately validated recovery procedure. Record all dependent data disks as part of the same migration set.

Step 1: Protect every required disk

Install and enroll the XReplicator agent inside the VMware guest. Configure protection for the complete operating-system disk and every data disk the workload requires. Before relying on the result, confirm that the source paths are whole disks rather than individual partitions or drive-letter volumes.

Run a baseline backup, allow the expected incremental backups to complete, and confirm that each required disk appears under the correct host in the XReplicator backup view. Do not proceed if the disk inventory in XReplicator differs from the inventory recorded inside the guest.

For multi-disk applications and databases, disk presence alone is not an application-consistency guarantee. Use the application's supported quiesce or shutdown procedure, and keep required logs, keys, and configuration with the migration evidence.

Step 2: Create the final cutover restore point

Choose a maintenance window and stop application writes. Run the final backup while the source VM is still available, wait for every required disk backup to finish, and verify the selected restore points.

After the final backup completes, power off the VMware VM or otherwise prevent new writes. Do not allow the source and migrated VM to run simultaneously with the same hostname, IP address, application identity, or writable data set.

Record the restore-point identifier selected for each disk. The operating-system and data-disk selections should belong to the same cutover window.

Step 3: Export the raw disk images

In the XReplicator UI:

• Open the backups for the source host.
• Select the operating-system disk and its final verified restore point.
• Choose Export raw image and save the .img file.
• Download the SHA-256 checksum for the same export.
• Repeat the export for every required data disk.

Name the files so their role and attachment order remain clear, for example:

• finance-app-os-disk0.img
• finance-app-data-disk1.img
• finance-app-data-disk2.img

Store the restore-point identifiers, image names, original disk sizes, and attachment order in the migration record.

Step 4: Verify every exported image

Verify the downloaded checksum before conversion with sha256sum -c finance-app-os-disk0.img.sha256.

If the checksum file is not available in that format, calculate and compare it directly with sha256sum finance-app-os-disk0.img.

Inspect the source image without modifying it with qemu-img info -f raw finance-app-os-disk0.img.

A failed checksum or unexpected virtual size stops the migration. Export the image again rather than attempting to repair an incomplete download.

Step 5: Convert raw images to QCOW2

For a guest that already contains the required KVM storage and network drivers, convert and check each image with qemu-img:

• qemu-img convert -p -f raw -O qcow2 finance-app-os-disk0.img finance-app-os-disk0.qcow2
• qemu-img convert -p -f raw -O qcow2 finance-app-data-disk1.img finance-app-data-disk1.qcow2
• qemu-img check -f qcow2 finance-app-os-disk0.qcow2
• qemu-img check -f qcow2 finance-app-data-disk1.qcow2

Run conversion only while the source images are offline and unused. Write to new destination files; do not convert over the verified raw exports.

qemu-img changes the disk container format. It does not install VirtIO drivers, rebuild the initramfs, repair a bootloader, or recreate the VM definition.

When to use virt-v2v instead

Use virt-v2v when the guest needs VMware-to-KVM adaptation, particularly for Windows guests or Linux guests whose boot path depends on VMware-specific storage drivers. Create the destination with mkdir -p /var/lib/libvirt/images/finance-app, then supply the operating-system disk first, followed by its data disks:

virt-v2v -i disk finance-app-os-disk0.img finance-app-data-disk1.img -o local -os /var/lib/libvirt/images/finance-app -of qcow2

virt-v2v inspects the guest and can modify supported operating systems so they boot with KVM devices. Review its output metadata and logs before importing the result. Availability and supported guest versions depend on the Linux distribution that packages virt-v2v.

Step 6: Create the KVM virtual machine

Create a new VM in libvirt, Proxmox, OpenStack, or the KVM management platform used by your organization. Match the recorded source requirements:

• Use the same CPU architecture.
• Match BIOS or UEFI firmware; do not switch firmware modes during the first boot.
• Attach the operating-system disk first and preserve the data-disk order.
• Allocate the required CPU and memory.
• Start on an isolated network to prevent identity or IP conflicts.
• Prefer VirtIO disks and networking after confirming that the guest contains the required drivers.

Raw images can also be attached directly to QEMU/KVM when the target platform permits it. QCOW2 is commonly preferred for file-based KVM storage because it supports sparse allocation and QEMU snapshot features.

Step 7: Run an isolated boot test

Boot the migrated VM without production network access. Use the virtual console for the first start and check:

• Firmware finds the expected bootloader.
• The operating system reaches a usable login state.
• All expected disks, partitions, filesystems, and drive letters are present.
• Filesystems are clean or recover normally after the captured point in time.
• Network interfaces and device names are understood before applying production addresses.
• Required services start and application data is present.
• Application owners can complete a representative functional check.

If the VM does not boot, retain the original raw images and diagnose the copied VM. Common causes include a BIOS/UEFI mismatch, missing VirtIO drivers, changed Linux device names, stale /etc/fstab entries, missing EFI partitions, bootloader configuration, or encrypted disks without their keys.

Step 8: Cut over or roll back

Once the isolated test passes, schedule the production network and DNS change. Keep the VMware VM powered off but available until the KVM workload is accepted.

Record the time required for image export, conversion, VM creation, first boot, application validation, and network cutover. If validation fails, power off the KVM copy and return to the unchanged VMware VM according to the agreed rollback plan.

What this workflow does not capture automatically

A raw disk image contains disk bytes. It does not contain the complete VMware VM configuration, CPU and memory settings, virtual switches, VLANs, firewall policy, passthrough devices, snapshots, or external application dependencies. Those details must be inventoried and recreated on the KVM platform.

This workflow also does not convert one CPU architecture into another, remove encryption, or prove database consistency from a successful disk export alone. Treat boot validation and application validation as required migration stages, not optional checks after the work is considered complete.

The result is a practical VMware exit path built on customer-controlled backups: protect the guest with XReplicator, export verified disk images, convert or adapt them with established KVM tools, and prove the recovered workload before production cutover.