DEV Community

Susant Sahani
Susant Sahani

Posted on

VMware to KVM Migration: Why Disk Conversion Is Only the Beginning

#virtualization #kvm #linux #devops

Moving a virtual machine from VMware to KVM sounds simple:

VMDK → QCOW2 → Boot
Enter fullscreen mode Exit fullscreen mode

In practice, that is often the easiest part.

A disk can convert perfectly and still leave you with a virtual machine that:

  • fails to find its root filesystem,
  • drops into an initramfs shell,
  • cannot see its virtual disk,
  • loses its network configuration,
  • fails because of firmware differences,
  • or boots into Windows recovery.

At Zyvor AI Labs, we see VM migration as a guest-operating-system problem as much as a disk-format problem.

That is one of the reasons we built hyper2kvm and GuestKit.

A converted disk is not a migrated VM

Tools such as qemu-img can convert virtual disk formats very effectively.

For example:

qemu-img convert -p \
  -f vmdk \
  -O qcow2 \
  source.vmdk \
  destination.qcow2
Enter fullscreen mode Exit fullscreen mode

At this point you have a QCOW2 image.

You do not necessarily have a bootable KVM virtual machine.

The guest operating system was originally installed against a particular virtual hardware environment.

Changing that environment can affect:

  • Storage controllers
  • Network adapters
  • Firmware
  • Bootloader configuration
  • Kernel modules
  • Device naming
  • Filesystem references
  • Windows drivers

Successful migration therefore requires understanding what is inside the disk.

Problem 1: Storage drivers

One of the most common migration issues is storage.

A VMware guest may have been running against VMware virtual storage hardware.

The KVM target may expose disks using VirtIO.

Linux generally has excellent VirtIO support, but the required modules still need to be available at the right point during boot.

Relevant modules can include:

virtio
virtio_pci
virtio_blk
virtio_scsi
Enter fullscreen mode Exit fullscreen mode

If the required storage driver is not available inside the initramfs, the kernel may start successfully but fail to locate the root filesystem.

The migration looks like it failed at KVM.

The real problem is inside the guest.

Problem 2: initramfs

Linux systems frequently depend on an initial RAM filesystem to load storage and filesystem modules before mounting the real root filesystem.

After changing virtual hardware, the existing initramfs may not contain what the new environment requires.

This is why migration tooling needs to inspect and, where required, rebuild the initramfs.

Depending on the distribution, that could involve tools such as:

dracut
Enter fullscreen mode Exit fullscreen mode

or:

update-initramfs
Enter fullscreen mode Exit fullscreen mode

The exact workflow differs across Linux distributions.

A migration system therefore needs to understand the guest rather than blindly apply one repair command.

Problem 3: GRUB and boot paths

The next problem is boot configuration.

A virtual machine may originally have been configured for:

  • BIOS
  • UEFI
  • GPT
  • MBR

The target environment needs to reproduce a compatible boot path.

GRUB configurations can also reference disks by:

  • UUID
  • filesystem label
  • /dev/sdX
  • /dev/vdX
  • LVM paths

Hard-coded device names are particularly fragile.

A VMware disk that appeared as:

/dev/sda
Enter fullscreen mode Exit fullscreen mode

could appear under KVM as:

/dev/vda
Enter fullscreen mode Exit fullscreen mode

if VirtIO block devices are used.

The filesystem still exists.

The operating system simply may not know where to find it.

Problem 4: /etc/fstab

Consider an entry like this:

/dev/sda2 / ext4 defaults 0 1
Enter fullscreen mode Exit fullscreen mode

After migration, /dev/sda2 may no longer exist under that name.

A more resilient system may use:

UUID=<filesystem-uuid> / ext4 defaults 0 1
Enter fullscreen mode Exit fullscreen mode

Migration assessment should therefore examine filesystem references before cutover.

Otherwise a perfectly healthy converted disk can fail during boot because one configuration file expects a device name that changed.

Problem 5: Windows is different

Windows migration introduces another set of challenges.

Moving a Windows VM from VMware to KVM may require making VirtIO drivers available before the machine boots on the target hypervisor.

Potential requirements include drivers for:

  • VirtIO storage
  • SCSI
  • Network adapters
  • Balloon devices

If Windows cannot access the boot disk through the new controller, it may fail long before a user can install the missing driver manually.

That means driver preparation often needs to happen offline, before first boot.

Problem 6: Networking

Even after the operating system boots, networking can still break.

The guest sees different virtual NIC hardware.

That can interact with:

  • MAC-address-based configuration
  • interface naming
  • static IP configuration
  • udev rules
  • NetworkManager profiles
  • netplan
  • systemd-networkd
  • legacy Linux network scripts

A machine that successfully reaches a login prompt but has no network connectivity is not a successful enterprise migration.

Validation must extend beyond "did it boot?"

This is why we built GuestKit

GuestKit approaches migration from the other direction.

Instead of first booting a migrated VM and discovering what broke, GuestKit examines the guest disk offline.

The idea is:

Inspect before cutover.
Enter fullscreen mode Exit fullscreen mode

GuestKit can analyze virtual disk formats such as:

  • VMDK
  • QCOW2
  • RAW

and gather information about what is inside the guest.

That can include areas such as:

  • Operating system identification
  • Boot configuration
  • Filesystems
  • Drivers
  • initramfs
  • GRUB
  • fstab
  • Potential migration blockers

The objective is to determine whether a guest is migration-ready before putting it into a cutover window.

Fleet migration changes the problem

Testing one virtual machine manually is manageable.

Testing 1,000 is not.

At fleet scale, migration teams need answers such as:

Which VMs are ready?
Which VMs require remediation?
Which Windows guests are missing drivers?
Which Linux guests have risky boot configurations?
Which systems should not enter the current migration wave?
Enter fullscreen mode Exit fullscreen mode

That requires structured inspection.

Instead of:

VM → migrate → boot → debug
Enter fullscreen mode Exit fullscreen mode

we prefer:

VM
 ↓
Offline inspection
 ↓
Readiness assessment
 ↓
Remediation plan
 ↓
Conversion
 ↓
Validation
 ↓
Cutover
Enter fullscreen mode Exit fullscreen mode

This allows infrastructure teams to move failure discovery earlier in the process.

hyper2kvm handles the migration workflow

Where GuestKit focuses on understanding the guest, hyper2kvm focuses on the actual VMware-to-KVM migration workflow.

The migration process can involve:

Source VM
   ↓
Disk acquisition
   ↓
Guest inspection
   ↓
Driver preparation
   ↓
Disk conversion
   ↓
Boot remediation
   ↓
Target configuration
   ↓
Validation
   ↓
KVM
Enter fullscreen mode Exit fullscreen mode

That is much closer to the real problem than treating migration as:

qemu-img convert
Enter fullscreen mode Exit fullscreen mode

Preflight matters

Enterprise migration projects should ideally identify problematic machines before the scheduled cutover.

A preflight system can ask:

Is the disk readable?

If not, stop.

Is the operating system identifiable?

If not, flag it.

Is the boot configuration understood?

If not, investigate.

Are target storage drivers available?

If not, inject or rebuild them.

Are filesystem mounts safe?

If not, remediate them.

Is the firmware configuration compatible?

If not, adjust the target definition.

Can we verify the resulting guest?

If not, do not treat conversion success as migration success.

Validation should be explicit

A migration pipeline should produce a clear result.

For example:

{
  "guest": "finance-db-07",
  "source": "vmware",
  "target": "kvm",
  "disk_conversion": "passed",
  "boot_readiness": "passed",
  "virtio_storage": "present",
  "network_review": "required",
  "migration_status": "ready_with_warning"
}
Enter fullscreen mode Exit fullscreen mode

That is far more useful than:

Conversion completed successfully.
Enter fullscreen mode Exit fullscreen mode

The first result tells an engineer what still needs attention.

The second only tells us that bytes were copied successfully.

The real migration unit is the guest

Hypervisors operate virtual hardware.

Applications run inside operating systems.

That distinction matters during migration.

If we only look at the disk format, we miss the systems responsible for actually starting the workload:

Firmware
   ↓
Bootloader
   ↓
Kernel
   ↓
Initramfs
   ↓
Storage
   ↓
Root filesystem
   ↓
Networking
   ↓
Application
Enter fullscreen mode Exit fullscreen mode

Every layer can introduce a migration failure.

Where we're taking this

At Zyvor, our goal is to make VMware-to-KVM migration more deterministic.

That means moving from:

Convert and hope

to:

Inspect → understand → remediate → convert → validate

hyper2kvm handles the migration path.

GuestKit provides offline intelligence about what is inside the guest.

And HyperSDK provides the broader orchestration layer around discovery, migration, validation, and infrastructure operations.

If you're planning VMware-to-KVM migrations, we're particularly interested in hearing about the failures that are hardest to automate.

What causes the most trouble in your environment: Windows drivers, bootloader issues, Linux initramfs, networking, or application validation?

Zyvor AI Labs
https://zyvor.dev

GuestKit:
https://zyvor.dev/blog/guestkit-offline-disk-intelligence

VMware → KVM migration:
https://zyvor.dev/blog/windows-vm-migration-kvm

Top comments (0)