Convert VMDK to QCOW2 & Convert QCOW2 to VMDK Using qemu-img

When working across different virtualization platforms, disk format compatibility becomes critical. VMware relies on VMDK (Virtual Machine Disk) files, while KVM/QEMU uses QCOW2 (QEMU Copy On Write) as its native format. Migrating workloads between these environments requires converting disks so they can run reliably in the target hypervisor. The qemu-img utility provides a fast, precise way to convert between VMDK and QCOW2, ensuring seamless cross‑platform virtualization.

In this guide, we’ll walk through the conversion process step‑by‑step, explain best practices, and highlight how to avoid common pitfalls when moving virtual machines between VMware and KVM/QEMU.

VMDK vs QCOW2 — Format Architecture and Differences

qemu-img convert -O qcow2 source.vmdk target.qcow2

qemu-img convert -p -O qcow2 -S 0 source.vmdk target.qcow2

qemu-img convert -c -O qcow2 source.vmdk target.qcow2

qemu-img check target.qcow2

How to Convert QCOW2 to VMDK for VMware

When migrating workloads from KVM/QEMU into VMware, you’ll need to convert QCOW2 to VMDK. The qemu-img utility makes this process straightforward, ensuring VMware can recognize and boot the disk properly.

qemu-img Reverse Conversion Command

Use the following syntax to convert a QCOW2 disk into a VMware‑compatible VMDK:

qemu-img convert -O vmdk source.qcow2 target.vmdk

• source.qcow2
  → path to the QCOW2 disk file
• target.vmdk → desired VMware disk file name
• -O vmdk → specifies VMware’s native format

For progress feedback, add -p:

qemu-img convert -p -O vmdk source.qcow2 target.vmdk

Preparing VMDK for ESXi / VMware Compatibility

• Place the converted .vmdk file into the VMware datastore or local storage.
• Create a new VM in VMware and attach the converted disk as the primary virtual hard drive.
• Ensure the VM’s hardware compatibility (CPU, memory, and firmware type) matches the guest OS requirements.

Fixing Disk Adapter and Boot Controller Issues

• VMware defaults to SCSI controllers, while KVM/QEMU often uses IDE/SATA.
• If the VM fails to boot, adjust the VMware VM settings to match the original controller type.
• For Windows guests, ensure the correct storage drivers (IDE/SATA/SCSI) are installed before conversion.
• For Linux guests, verify kernel modules support the chosen controller.

KVM Migration Strategy — Moving VMware VM to KVM Safely

Migrating a virtual machine from VMware to KVM requires careful planning to ensure the VM boots correctly and performs well after conversion. The process involves disk conversion, VM rebuild, driver adjustment, and compatibility checks.

Disk Conversion → VM Rebuild → Driver Adjustment

• First, convert VMDK to QCOW2 using qemu-img convert -O qcow2 source.vmdk target.qcow2.
• Next, rebuild the VM definition in KVM (via virt-manager or libvirt XML) and attach the converted QCOW2 disk.
• Finally, adjust drivers and controllers to match KVM defaults (usually VirtIO for storage and network).

VirtIO Driver Requirement

• KVM relies on VirtIO drivers for optimal disk and network performance.
• Windows guests may require manual installation of VirtIO drivers before migration.
• Linux guests typically include VirtIO support by default, but verify kernel modules are loaded.

BIOS vs UEFI Compatibility

• VMware VMs may use either BIOS or UEFI firmware.
• Ensure the KVM VM definition matches the original firmware type.
• A mismatch (e.g., UEFI disk booted under BIOS) can prevent the VM from starting.

Disk Format Optimization After Conversion

Once you’ve converted virtual disks between VMDK ↔ QCOW2, it’s important to fine‑tune them for performance, storage efficiency, and long‑term reliability.

Sparse vs Preallocated QCOW2

• Sparse (thin‑provisioned) QCOW2 files only consume space as data is written, saving storage but potentially fragmenting over time.
• Preallocated QCOW2 files reserve full disk size upfront, improving performance consistency.
• Choose sparse for flexibility and testing, preallocated for production workloads where predictable I/O is critical.

Compression and Cluster Size Tuning

1. 1. QCOW2 supports compression during conversion (qemu-img convert -c) to reduce disk footprint.
2. 2. Cluster size (default 64 KB) can be tuned for workload type:

• Smaller clusters → better space efficiency for many small files.
• Larger clusters → better performance for sequential workloads.

Resize and Compact Disk

• Use qemu-img resize target.qcow2 +10G to expand disk capacity.
• Run qemu-img convert -O qcow2 target.qcow2 compact.qcow2 to reclaim unused space and shrink disk size.
• Compacting helps maintain efficiency after large deletions inside the guest OS.

Performance vs Storage Tradeoffs

• Thin + compression → saves space but may reduce performance.
• Preallocated + larger clusters → improves speed but consumes more storage.
• Balance based on workload: development/test environments benefit from thin disks, while production databases or high‑I/O systems perform best with preallocated disks.

Common Conversion Problems and How to Fix Them

Even with reliable tools like qemu-img, disk conversions between VMware (VMDK) and KVM/QEMU (QCOW2) can encounter issues. Below are the most frequent problems and their solutions.

Disk Inflation / Unexpected Size Growth

• Problem: Thin‑provisioned VMDKs may inflate into large QCOW2 files during conversion, consuming more storage than expected.
• Fix: Use qemu-img convert -S 0 to preserve sparsity and prevent unnecessary disk growth. Always check available storage before conversion.

Unsupported or Split VMDK Chains

• Problem: VMware often creates split VMDKs or snapshot chains that qemu-img cannot handle directly.
• Fix: Consolidate snapshots and merge split disks into a single monolithic VMDK using VMware tools (vmware-vdiskmanager) before conversion.

Descriptor File Missing or Corrupted

• Problem: VMDKs rely on descriptor files to define disk geometry. If missing or corrupted, conversion fails.
• Fix: Rebuild the descriptor file using VMware utilities or restore from backup. Without a valid descriptor, qemu-img cannot interpret the disk.

VM Fails to Boot After Conversion

• Problem: Even after successful conversion, the VM may not boot due to driver or controller mismatches.
• Fix: Adjust the VM definition in KVM to match the original firmware (BIOS/UEFI) and ensure VirtIO drivers are installed for storage and network. Boot into recovery mode if necessary to repair drivers.

Wrong Disk Controller (IDE / SCSI / VirtIO)

• Problem: VMware defaults to SCSI, while KVM often uses VirtIO or SATA. A mismatch can cause “inaccessible boot device” errors.
• Fix: In KVM, attach the disk to the correct controller type. For Windows guests, install VirtIO drivers before migration; for Linux guests, verify kernel modules support the chosen controller.

Advanced Conversion Scenarios

Beyond straightforward disk conversions, administrators often face complex situations that require careful handling to avoid data loss or performance issues.

Convert Snapshot Chains Safely

• Challenge: VMware VMDKs may exist as snapshot chains, with multiple delta files linked to a base disk.
• Risk: Converting only a delta file can result in incomplete or corrupted data.
• Solution: Always consolidate snapshots into a single monolithic VMDK using VMware tools before running qemu-img. This ensures the converted QCOW2 contains the full VM state.

Convert Large Enterprise Disks

• Challenge: Enterprise workloads often use disks hundreds of GBs or even multiple TBs in size.
• Risk: Conversion can be slow, resource‑intensive, and prone to storage bottlenecks.
• Solution: Run conversions on hosts with sufficient free space and I/O capacity. Consider using preallocation (-o preallocation=falloc or full) for predictable performance in production environments.

Live Migration vs Offline Conversion

• Challenge: Deciding whether to migrate a VM while it’s running (live) or shut it down first (offline).
• Risk: Live migration introduces complexity and potential data inconsistency if not carefully managed.
• Solution: For critical workloads, prefer offline conversion — shut down the VM, convert the disk, and rebuild in KVM. Live migration may be suitable for non‑critical workloads but requires advanced orchestration tools and snapshot synchronization.

Recovering Virtual Machine Files After Failed Disk Conversion

Disk conversions between VMware (VMDK) and KVM/QEMU (QCOW2) don’t always succeed. When the process is interrupted or misconfigured, virtual machine files can become corrupted, deleted, or unreadable — putting critical workloads at risk.

Real Recovery Scenarios

• Interrupted conversion → corrupted VMDK/QCOW2. A failed or incomplete conversion may leave the disk partially written, making it unusable in either hypervisor.
• Lost descriptor → unreadable virtual disk. VMware VMDKs rely on descriptor files to define disk geometry. If missing or corrupted, the VM cannot recognize the disk.
• Datastore corruption during migration. Storage instability or network errors can damage the VMFS datastore, affecting multiple VMs at once.
• Deleted VM after failed format change. Administrators may accidentally delete VM files while attempting recovery, compounding the problem.

Professional Recovery Approach

When standard tools fail, professional recovery software is required to restore VM data before attempting disk reconstruction or reconversion.

DiskInternals VMFS Recovery™ restores:

• Corrupted or deleted VMDK virtual disks
• VM configuration and metadata files (VMX)
• Entire virtual machines from damaged VMFS datastores
• Data before rebuilding the VM or reconverting the disk

Best Practices for Safe VMDK ↔ QCOW2 Conversion

Converting virtual disks between VMware and KVM/QEMU requires careful preparation to avoid corruption, boot failures, or performance issues. Following these best practices ensures reliable results:

• Backup disk before conversion. Always create a full backup of the original VMDK or QCOW2 file. This protects against data loss if the conversion process is interrupted or fails.
• Consolidate snapshots first. VMware snapshot chains must be merged into a single monolithic VMDK before conversion. Converting only a delta file can result in incomplete or corrupted disks.
• Verify disk integrity post‑conversion. Use qemu-img check target.qcow2 or qemu-img check target.vmdk to confirm the converted disk is valid and free of corruption.
• Match correct disk controller (VirtIO / SCSI). Ensure the VM definition in KVM or VMware uses the same controller type as the original environment. Mismatches often cause “inaccessible boot device” errors.
• Test VM boot in isolated environment. Before deploying in production, boot the converted VM in a sandbox or test environment to validate drivers, firmware settings (BIOS/UEFI), and overall stability.

FAQ