What is a VM migration? Factors that impact cross-hypervisor moves (VMware to KVM)

What are you actually moving in a VMware to KVM migration?

You're moving two things: a VM definition and one or more disks. The definition is metadata. It covers vCPUs, memory, NICs, the firmware the guest expects and the shape of its virtual hardware. The disks are the bulk of the payload: operating system, applications and data.

The two platforms describe that definition in completely different languages. VMware keeps it in a .vmx file (and an OVF descriptor on export). KVM, through libvirt, uses its own domain XML, with different hardware models and defaults. No clean file swap gets you from one to the other, so reconciling them is interpretive work. That mismatch is what makes every VMware KVM move hard, and the same applies for Xen-based or Hyper-V-based targets.

Why are same-hypervisor moves easy and cross-hypervisor moves hard?

ESXi to ESXi, or KVM to KVM, is easy because the definition is portable and the hypervisor does the heavy lifting. Going from VMware to KVM, you convert the disk format and rebuild the VM definition in the target's language at the same time. You are not copying a VM. You are transforming one.

What should you check before you start?

Before each VM migration, check five things on the source VM and the conversion host.

• No snapshots on the VM before you enable CBT (KB 320557, see step 2).

• Windows: Fast Startup and hibernation off (both block conversion, per the virt-v2v manual), then a clean shutdown.

• The MAC address of every NIC and the firmware type (BIOS or UEFI), written down.

• virtio-win on the conversion host, plus fast, direct access to the destination storage.

• TCP 443 to vCenter, and TCP 443 and 902 to ESXi, as the CloudStack import docs list.qemu-img: disk format conversion

Step 1. Which tools do you need: qemu-img, virt-v2v or vJailbreak?

A common toolchain has three layers: qemu-img converts disk images, virt-v2v converts the guest, and vJailbreak builds on virt-v2v for fleet-scale moves. Equivalent stacks exist, open source and proprietary, but whatever you use to migrate VMware to KVM has these layers underneath.

qemu-img: disk format conversion

At the bottom sits qemu-img. It does one job: convert disk images between formats, such as VMDK to QCOW2 or raw. It knows nothing about the operating system inside the disk, only the bytes and the container format around them.

virt-v2v: the VMware to KVM conversion engine

A layer up is virt-v2v, which does the actual conversion. It reads the VM from VMware and copies the disks, using nbdkit and nbdcopy in current releases. Then it works inside the guest filesystem, strips VMware drivers and agents, injects virtio and fixes the boot configuration. The output is readied disks plus a libvirt-shaped definition. Per the virt-v2v manual, it converts guests to run on KVM, managed by libvirt, OpenStack, oVirt or other targets.

vJailbreak: fleet-scale orchestration

virt-v2v migrates one VM at a time and knows nothing about your fleet. vJailbreak builds on it for migrations at scale. It connects to vCenter to discover VMs, supports scheduling and follows virt-v2v's OS support. The vJailbreak README describes a free Platform9 tool for moving VMs "from VMware to any OpenStack-compliant cloud".

In short: qemu-img converts disk images by hand. virt-v2v copies the disks and makes the guest bootable on KVM. vJailbreak builds on virt-v2v to run it across an estate. You can drop down a level when you need the control, but in our experience large migrations run on the higher ones.

Migration tools for VMware to KVM, by layer

Apache CloudStack, which we're testing internally as our orchestration target, has its own VMware import, so there you'd use that instead of vJailbreak. Our 18 March 2026 post on moving from OpenStack to CloudStack explains why OpenStack wasn't the fit for this work, despite a decade of production experience with it. Our production cloud platform runs on OpenStack today.

CloudStack's import calls virt-v2v on a KVM host where you install it yourself. The CloudStack docs (checked 15 October 2026) recommend 2.7.x on EL9 or 2.4.x on Ubuntu 24.04, not 1.4.x, so check virt-v2v --version first.

Step 2. How do you enable Change Block Tracking on the source VM?

Remove all snapshots, power off the VM, then add one Change Block Tracking (CBT) parameter for the VM and one per disk. CBT is a VMware feature that tracks which blocks of a VMDK changed since a given point in time.

Do this before the first full copy, since every later sync builds on it. Following Broadcom's KB 315370, add these to the advanced configuration, with one scsiX:Y line per disk:

ctkEnabled = true

scsi0:0.ctkEnabled = true

Power on and check for a <vmname>-ctk.vmdk file next to each disk. KB 320557 warns that an earlier snapshot can make QueryChangedDiskAreas, the call that lists changed blocks, return wrong data.

Step 3. Export an OVA or read straight from vCenter?

You can export the VM as OVF or OVA and convert the files, or let virt-v2v read it straight from vCenter or ESXi. An export gives you a file to stage and keep. A direct read skips the intermediate copy.

VMware stores disks as VMDK (Virtual Machine Disk). An export gives you an OVF (Open Virtualization Format) package: an XML descriptor plus the VMDK files, often bundled as one OVA tar archive. The descriptor is the portable statement of what the VM looks like. The VMDKs are the data.

The virt-v2v manual documents both routes. The first command is the manual's vCenter example, and we composed the second from the flags it documents:

# Read from vCenter (default output: libvirt)

virt-v2v -ic vpx://vcenter.example.com/Datacenter/esxi vmware_guest

# Read an exported OVA into local QCOW2 files (composed from the documented flags)

virt-v2v -i ova guest.ova -o local -os /var/tmp -of qcow2

For VMware's VDDK library, use -it vddk with -io vddk-libdir=... and -io vddk-thumbprint=... (there's no --vddk flag). The CloudStack docs say this route copies only allocated blocks. Pass passwords with -ip as a file (mode 0600, no trailing newline).

Step 4. How do you convert VMDK to QCOW2 with qemu-img?

Run one qemu-img convert command per disk. qemu-img rewrites the container format and leaves the guest operating system untouched.

qemu-img convert -p -f vmdk -O qcow2 source-disk.vmdk output-disk.qcow2

-p shows progress, and -f and -O set the source and output formats. The QEMU documentation lists the rest, including -n, which skips creating the target.

KVM mostly uses QCOW2 (QEMU Copy-On-Write version 2), which gives you thin provisioning, snapshots and backing files. Many production setups use raw block devices backed by Ceph RBD, LVM or similar instead. Either way, VMDK has to become QCOW2 or raw, by hand or through virt-v2v.

VMDK comes in several subtypes. The QEMU disk image docs list monolithicSparse, monolithicFlat, twoGbMaxExtentSparse, twoGbMaxExtentFlat and streamOptimized.

Convert large disks straight onto the target storage, because staging them locally doubles your I/O and disk usage for no reason. On Ceph, qemu-img can write straight to an RBD image (see the QEMU and Ceph docs), so you don't import a QCOW2 file later. The qemu-img docs describe -n for targets you created beforehand, such as RBD images with site-specific options. The same goes for iSCSI or NAS storage. So your migration server, the environment that runs these tools and is part of your new platform, needs direct and fast access to the destination storage.

Keep exported OVA files and rollback copies in S3-compatible Object Storage until the move is signed off.

Step 5. How do you run the VMware to KVM conversion with virt-v2v?

Point virt-v2v at the shut-down source and pick an output. Its support page covers Windows guests from XP to Windows 11 and Server 2025, and Linux guests such as RHEL, Debian and Ubuntu.

The guest must be cleanly shut down, because the virt-v2v manual warns that converting a running guest can corrupt its filesystem. So the real run belongs in the cutover window, on the final synced disks.

Windows needs virtio-win on the conversion host, in /usr/share/virtio-win/virtio-win.iso or wherever VIRTIO_WIN points, plus rhsrvany.exe. Inside the guest, Fast Startup and hibernation must be off. Dynamic system disks aren't supported, and Windows 7 and Server 2008 R2 need an SHA-2 update.

Guest cleansing and VM rebuilding on KVM

A VM that grew up on VMware is full of VMware-specific assumptions. VMware Tools, vmxnet drivers and guest agents become dead weight. The guest needs virtio drivers instead, because KVM presents disks and NICs most efficiently as virtio devices. This matters most on Windows, which won't boot off a disk controller it has no driver for. Get it wrong and you have an unbootable VM at cutover.

You don't do most of this by hand. virt-v2v runs the guest-side cleansing for Windows and Linux guests and outputs readied volumes for a freshly defined guest. Windows has one catch: virt-v2v tries to remove VMware Tools at first boot, but the virt-v2v manual notes that VMware's uninstaller often fails with error 1603. Plan a manual clean-up. Tools that build on virt-v2v, such as vJailbreak, repeat this across the estate and land the results in the target cloud. In our experience, that conveyor belt is what large migrations are built around.

Step 6. How do incremental syncs shrink the delta?

Each incremental sync copies only the blocks CBT marks as changed since the last copy, so every pass is smaller than the one before.

Steps 2 to 6 form one loop. Here's a strategy that works with these tools, and as far as I know it's a common one:

1. Initial sync. With the VM still running, copy the full disk to the target. For a large disk this might take hours, while the workload stays online.

2. Incremental syncs. Use CBT to find the changed blocks and transfer only those. Repeat until the delta is small.

Neither the virt-v2v manual nor the vJailbreak README documents CBT-driven syncs, so you build that loop around the tools yourself.

Step 7. Can you live migrate VMware to KVM, or is a virt-v2v cutover always cold?

Not with virt-v2v, which needs a cleanly shut-down guest for the final conversion. CloudStack's import requires Windows VMs to be shut down and recommends it for Linux. There's no vMotion from ESXi into KVM either.

The formats and hardware models are too different to hand off a running machine. To convert VMware to KVM with virt-v2v, you power off the VM so its disks hold a consistent final state. The vJailbreak README lists hot and cold migrations without defining either, so test what its hot mode means for your workloads before you plan around it.

Cold doesn't have to mean hours of downtime, though, and to the customer it can feel close to hot. CBT decouples the bulk transfer from the cutover:

3. The cut-off period. Schedule a short maintenance window. Power off the VM, run one final incremental sync, do the conversion and definition rebuild, and boot on KVM.

Downtime drops from the whole transfer to the final delta plus conversion and boot. Disk size and change rate decide how long that takes. That cut-off window is the part of a VMware to KVM migration customers notice, especially with larger service VMs in a non-redundant setup.

Step 8. How do you land the VM in the right network?

Drop it into the same Layer 2 network it lived in before. The VM can then keep its IP, its gateway and its links to load balancers, database peers and firewalls, so far less needs to change.

Getting the VM booting is only half the job, and here your network designs either help you or fight you. Say you run VMware without NSX. A flat, VLAN-based target that mirrors the source reuses existing capacity and keeps a Galera cluster or HAProxy pair on one segment. An SDN model (VXLAN, routing on the host or EVPN) gives you flexibility and scale. Without a compatible Layer 2, though, every migrated VM becomes a small re-engineering job: new addressing, revisited routing and VNF appliances, and HA to revalidate.

For a like-for-like MSP migration, make the target network look as much like the source as you can, and save fancier topologies for greenfield workloads. You can try to integrate your new platform into the existing network, even with an SDN. Based on our experience so far this is very hard, especially with SDNs driven by the orchestrators above them. virt-v2v's --mac option maps NICs to target networks or bridges, but it can't change a MAC address.

Step 9. How do you validate the guest after boot?

Check the MAC address, firmware, virtio devices and application health before you reopen traffic.

The original MAC keeps DHCP reservations, hardware-tied licensing and MAC-based policies working. Firmware (BIOS vs UEFI), disk controller and device naming must match the rebuilt definition, or the guest panics on boot. UEFI guests need a UEFI-capable target and matching OVMF versions, per the support page.

• MAC matches your pre-flight record.

• Firmware unchanged, with disks and NICs on virtio.

• No VMware Tools left on Windows guests.

• Applications answer and HA peers rejoin.

How do you roll back if the VM doesn't boot?

Keep the source VM powered off, not deleted, until the KVM copy passes validation. Rolling back then means powering the source on again. Once the KVM copy takes production writes, that option costs data, so agree a rollback deadline before cutover.

Why does the VM show "no bootable device" after conversion?

The VM usually can't find a boot disk because the firmware or disk controller doesn't match what the guest expects. A guest converted with qemu-img alone can also fail to boot, since qemu-img adds no virtio drivers.