VMFS Recovery™
Recover data from damaged or formatted VMFS disks or VMDK files
TRY IT FREEVer 4.28, WinBUY NOWFrom $699
Last updated:

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.

Why Convert VMDK and QCOW2 Virtual Disks


Virtual disk conversion between VMware and KVM/QEMU environments is often necessary to ensure compatibility, portability, and performance.

  • VMware → KVM migration. When moving workloads from VMware to KVM, converting VMDK disks into QCOW2 format allows seamless integration with QEMU/KVM, which relies on QCOW2 as its native disk type.
  • KVM → VMware reverse migration. In scenarios where workloads need to be moved back into VMware, converting QCOW2 disks into VMDK ensures the VM can boot and operate correctly in VMware’s environment.
  • Cross‑hypervisor portability. Converting between formats enables administrators to run the same VM across multiple hypervisors, improving flexibility and reducing vendor lock‑in.
  • Disk optimization and recovery workflows. QCOW2 supports advanced features like compression and snapshots, while VMDK offers broad compatibility. Conversion allows administrators to choose the format best suited for performance, storage efficiency, or recovery needs.
Note: VMware vs Qemu

VMDK vs QCOW2 — Format Architecture and Differences

FeatureVMDK (VMware)QCOW2 (QEMU/KVM)
Native platformVMware / ESXiKVM / QEMU
SnapshotsExternal chainsInternal snapshot support
Thin provisioningYesYes
CompressionNoYes
EncryptionLimitedSupported
Sparse disk efficiencyMediumHigh

How to Convert VMDK to QCOW2 Using qemu-img (Primary Method)

The most reliable way to convert VMDK to QCOW2 for KVM/QEMU is by using the qemu-img utility. This tool is built into QEMU and provides precise control over disk conversion, ensuring compatibility and performance.

qemu-img Command Syntax

The basic command to convert a VMware VMDK into a QCOW2 disk is:

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

  • convert → tells qemu-img to perform a format conversion
  • -O qcow2 → specifies the output format
  • source.vmdk → path to the VMware disk file
  • target.qcow2 → name of the new QCOW2 disk

Step-by-Step Conversion Process

  1. 1. Locate the VMDK file you want to convert.
  2. 2. Open terminal on your KVM/QEMU host.
  3. 3. Run the qemu-img convert command with correct paths.
  4. 4. Wait for the conversion to complete — progress depends on disk size.
  5. 5. Attach the new QCOW2 file to your KVM/QEMU VM definition (via virt-manager or libvirt XML).

Preserving Thin / Sparse Disk Without Inflation

  • By default, conversion may inflate sparse VMDK files.
  • Use the -p flag for progress and -S 0 to preserve sparsity:

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

  • This ensures thin‑provisioned disks remain efficient after conversion.

Choosing Preallocation and Compression Options

  1. 1. Preallocation:
  • -o preallocation=metadata → faster VM startup, slightly larger disk size.
  • -o preallocation=falloc or full → allocates full space upfront for performance.
  1. 2. Compression:
  • QCOW2 supports compression; use -c to reduce disk size during conversion.
  • Example:

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

Verify Converted QCOW2 Disk Integrity

  • Run:

qemu-img check target.qcow2

  • This validates the QCOW2 file structure and ensures no corruption.
  • Always boot the VM in a test environment before production use.
Tip: Qemu vs VirtualBox vs VMware

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.
Tip: All you need to know about VMFS datastore

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.
Note: What to do with damaged VMDK

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.

Conversion vs Migration vs Disk Clone — Critical Differences

MethodPurposeRiskOutput
ConvertChange disk formatLowQCOW2 / VMDK
CloneDuplicate diskVery lowSame format
Full migrationMove entire VMMediumBootable VM

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

Ready to get your data back?

To start recovering your data, documents, databases, images, videos, and other files, press the FREE DOWNLOAD button below to get the latest version of DiskInternals VMFS Recovery® and begin the step-by-step recovery process. You can preview all recovered files absolutely for FREE. To check the current prices, please press the Get Prices button. If you need any assistance, please feel free to contact Technical Support. The team is here to help you get your data back!

FREE DOWNLOADVer 4.28, WinBUY NOWFrom $699

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.

Conclusion — Reliable Cross‑Hypervisor Disk Conversion Strategy

  • Use qemu‑img for precise format conversion. The qemu-img utility is the most dependable tool for converting between VMDK and QCOW2, ensuring compatibility across VMware and KVM/QEMU environments.
  • Preserve sparse disk to avoid inflation. Always apply options that maintain thin provisioning during conversion to prevent unnecessary disk growth and wasted storage space.
  • Recover VM data first if the disk becomes unreadable. If a conversion fails or corrupts the disk, prioritize restoring VM files with professional recovery tools before attempting reconstruction or reconversion.
Note: VMware vs KVM and oVirt vs KVM comparison

FAQ

Related articles

FREE DOWNLOADVer 4.28, WinBUY NOWFrom $699