A junior on my team asked me last week, “How do I move a VM from VMware to KVM without losing data or breaking the network?” It’s a solid question — not because the tools are missing, but because the failure points are subtle: disk format quirks, firmware mismatches, and driver assumptions baked into the guest OS.
Yes, you can migrate a VM from VMware to KVM cleanly. But success depends on understanding what happens during disk conversion, how bootloaders resolve root devices across hypervisors, and why paravirtualized drivers matter even when the underlying hardware is abstracted.
This vmware to kvm migration guide covers the mechanics, not just the commands. You’ll see exactly how qemu-img handles VMDK variants, why virtio breaks first boot on unprepared guests, and how to repair initramfs when the kernel panics on boot. One migration once left me stuck for two hours because /dev/sda became /dev/vda — and the fix wasn’t obvious until I checked the initramfs modules.
Let’s walk through it step by step.
💾 Disk Conversion — The Core of Migration
The most critical step in any vmware to kvm migration is converting the disk: transforming VMware’s .vmdk into KVM’s preferred .qcow2.
The underlying mechanism is handled by qemu-img, which uses QEMU’s block layer to parse the source format, read each allocated block, and write it into a new image using a copy-on-write metadata structure. This allows .qcow2 to support snapshots, compression, and sparse allocation — features absent in raw images.
qemu-img convert -f vmdk -O qcow2 /path/to/vm-disk.vmdk /path/to/vm-disk.qcow2
The -f vmdk flag explicitly tells qemu-img to interpret the input as a VMware disk; -O qcow2 sets the output format. Without these, autodetection can fail, especially on stream-optimized or split disks.
Not all .vmdk files are the same. If the disk is split into 2GB segments (e.g., disk-000001.vmdk, disk-000002.vmdk), you must point qemu-img to the descriptor file — typically the first file in the sequence, often named disk.vmdk — not the -flat extents.
# For split disks, use the descriptor
qemu-img convert -f vmdk -O qcow2 disk.vmdk vm-disk.qcow2
Verify the output:
qemu-img info vm-disk.qcow2
Expected output:
image: vm-disk.qcow2
file format: qcow2
virtual size: 40 GiB (42949672960 bytes)
disk size: 8.2 GiB
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
If virtual size matches the original and disk size is significantly smaller (indicating sparse efficiency), the conversion succeeded.
“Migration isn’t about copying bits — it’s about preserving context.”
🛠️ Handling Corrupted or Inaccessible Disks
Some .vmdk files, particularly those exported via OVF, use stream-optimized format. These often fail to open:
qemu-img: Could not open 'bad-disk.vmdk': Invalid argument
To fix, re-serialize the disk into a flat format before conversion:
# First, de-serialize it
qemu-img convert -O vmdk stream-optimized.vmdk temp-flat.vmdk
# Then convert to qcow2
qemu-img convert -f vmdk -O qcow2 temp-flat.vmdk final.qcow2
This strips the stream optimization, making it parseable by qemu-img.
🧠 Why qcow2 Over raw?
You could use raw, but .qcow2 is better for production. While raw is a direct byte stream, .qcow2 adds:
- Snapshots (via internal L1/L2 metadata tables)
- Compression (optional, zlib-based)
- Encryption (supported in qcow2 v3)
- Sparse allocation (only allocates space for written clusters)
For example, a 40G virtual disk with 8G used will consume ~8.2G on disk as .qcow2, but always 40G as raw. The overhead of metadata is negligible; the flexibility is not.
I'd default to .qcow2 unless you're passing the disk directly to LVM or require deterministic I/O latency.
⚙️ VM Configuration — Matching Hardware Layers
A VM is more than a disk. It includes emulated CPU, memory layout, firmware, and device models. VMware and KVM differ here — mismatching them causes boot or driver failures.
VMware typically uses BIOS firmware , IDE/SATA controllers , and e1000/vmxnet3 NICs. KVM defaults to UEFI , virtio-blk , and virtio-net — faster, but not universally supported in older guests.
If the guest OS lacks virtio drivers, it won’t detect the disk or network — leading to boot hangs or kernel panics.
Start with a VM definition that matches the original hardware closely. Use virt-install or define a domain via virsh define. Example XML:
<domain type='kvm'>
<name>my-migrated-vm</name>
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
<vcpu placement='static'>2</vcpu>
<os>
<type arch='x86_64' machine='pc-q35-6.2'>hvm</type>
<boot dev='hd'/>
</os>
<devices>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/vm-disk.qcow2'/>
<target dev='vda' bus='virtio'/>
</disk>
<interface type='network'>
<source network='default'/>
<model type='virtio'/>
</interface>
</devices>
</domain>
Note `` — this enables paravirtualized networking, which reduces CPU overhead by ~30% compared to emulated NICs.
But if the guest was running on VMware with e1000, it likely doesn't have virtio-net drivers. Boot will fail silently.
🔧 Fallback: Use Emulated NICs for First Boot
To ensure bootability, switch to an emulated NIC model:
<interface type='network'>
<source network='default'/>
<model type='e1000'/> <!-- or 'rtl8139' -->
</interface>
e1000 is widely supported in Linux and Windows. After boot, install virtio-net drivers and switch back.
💾 Disk Bus: IDE vs. virtio
Same principle applies to storage. If the OS lacks virtio-blk (common in Windows Server 2008 or minimal CentOS installs), change the bus:
<target dev='hda' bus='ide'/>
Boot the VM, install the virtio drivers (e.g., from the Fedora virtio ISO), then reconfigure for virtio to gain ~40% better disk throughput.
🧩 Boot Issues — Fixing the Unbootable VM
You've converted the disk and defined the VM. It powers on — but hangs or panics.
This is where most migrations fail. The most common cause is initramfs not loading virtio modules , or GRUB referencing the wrong root device.
Attach to the console:
virsh console my-migrated-vm
If you see:
[ 0.000000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
The kernel can’t find the root partition.
Why? The initramfs was built for VMware’s SCSI driver (sd* devices), but KVM presents the disk as virtio-blk (vd*). The root device path in GRUB still says /dev/sda1, but the actual block device is /dev/vda1.
🛠️ Chroot Rescue with a Live ISO
Mount a rescue ISO:
virsh attach-disk my-migrated-vm /path/to/ubuntu-rescue.iso sdb --type cdrom
Reboot, enter BIOS, and boot from CD.
Mount the root filesystem:
mount /dev/vda1 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
Rebuild initramfs with virtio support:
# On Debian/Ubuntu
update-initramfs -u
# On RHEL/CentOS
dracut --force
Check /etc/default/grub:
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 root=/dev/vda1"
Ensure root= points to the correct virtio device (vda, vdb, etc.).
Update GRUB configuration:
update-grub # Debian
grub2-mkconfig -o /boot/grub2/grub.cfg # RHEL
Exit, reboot, and detach the ISO.
🧠 Why This Happens: Device Layer Abstraction
Linux uses major and minor device numbers to map block devices. VMware’s virtual SCSI controller uses major 8 (sda, sdb), while virtio-blk uses major 252 (vda, vdb). If the initramfs doesn’t include virtio_pci and virtio_blk modules, the device isn’t available at boot — so the kernel can’t mount the root filesystem.
This isn’t a KVM bug. It’s a consequence of how Linux abstracts hardware — and how initramfs is built for a specific driver set.
🤝 Final Network Handoff — Ensuring Connectivity
The VM boots, but has no network.
Check interface status:
ip link show
If eth0 exists but has no IP, investigate:
- Is
dhclientrunning? - Is the firewall blocking DHCP?
- Did the MAC address change?
It did. VMware used one MAC, KVM generated a new one. Some systems (especially RHEL derivatives) bind network configuration to MAC addresses in files like /etc/sysconfig/network-scripts/ifcfg-eth0.
Fix: edit or regenerate the config. Remove or update the HWADDR or MACADDR line.
Better: switch to predictable interface names (e.g., enp1s0) or use netplan with DHCP on Ubuntu 18+.
To avoid issues, pin the MAC in the VM XML:
<interface type='network'>
<mac address='52:54:00:12:34:56'/>
<source network='default'/>
<model type='virtio'/>
</interface>
This ensures consistency across reboots.
And if the original VM used a static IP, make sure it doesn’t conflict with existing leases.
🟩 Final Thoughts
Migrating a VM from VMware to KVM isn't just a format conversion. It's a shift in virtual hardware assumptions — from emulated devices to paravirtualized ones, from BIOS to UEFI, from SCSI semantics to virtio.
Each step — qemu-img convert, update-initramfs, virsh console — exposes dependencies we usually ignore: how initramfs resolves devices, how GRUB passes kernel parameters, how drivers map to block and network interfaces.
When the migration fails, it’s rarely the tooling. It’s the missing context.
But when it works, you’re not just running the same workload on new infrastructure. You’ve validated your understanding of the stack — from disk format internals to kernel boot flow.
This vmware to kvm migration guide isn’t about avoiding failure. It’s about knowing exactly where and why it happens — so you can fix it before the monitoring alert fires.
❓ Frequently Asked Questions
Can I migrate Windows VMs the same way?
Yes, but Windows needs virtio drivers installed beforehand or via rescue mode. Use the Fedora virtio ISO to attach drivers during setup.
Do I lose performance moving from VMware to KVM?
No — KVM is often faster for Linux workloads due to tighter kernel integration. Use virtio for disk and network, and enable KSM and transparent huge pages for memory efficiency.
Is live migration possible?
Not directly from VMware to KVM. You must power down the VMware VM, convert the disk, and boot on KVM. Use this during maintenance windows.