How to Convert VMDK to QCOW2: Linux, Proxmox & Windows

Moving a VM from VMware to a KVM-based hypervisor like Proxmox means dealing with an immediate compatibility problem: QEMU cannot boot a VMDK file directly, and renaming the extension will not fix it. A proper format conversion is required.

This guide covers VMDK-to-QCOW2 conversion on Linux, Proxmox, and Windows, including the qemu-img workflow, Proxmox’s importdisk process, and virt-v2v for cases where driver reconfiguration is needed. A troubleshooting table at the end covers the most common boot errors.

VMDK vs. QCOW2: What’s the Difference?

Before starting the conversion, it helps to understand why these two formats are not interchangeable.

VMDK is VMware’s native disk format, used across ESXi and VMware Workstation. QCOW2 is the native format for QEMU and KVM, with built-in support for snapshots, compression, and AES encryption. It is the default for Proxmox and most OpenStack deployments.

You cannot simply rename a .vmdk file to .qcow2. The hypervisor will fail to find valid boot headers and the VM will not start. A proper conversion rebuilds the internal data structures so the disk works correctly under KVM.

Before You Start: Pre-Conversion Checklist

Skipping these steps is the most common reason conversions produce corrupted images or VMs that fail to boot.

• Inspect the source VMDK first. Run qemu-img info source.vmdk to confirm the file size, format, and disk type before converting.
• Commit all snapshots. Converting a VMDK that is part of a snapshot chain usually results in an outdated or incomplete image. Delete or merge all snapshots in VMware first so you are working with a single, current disk file.
• Identify the correct VMDK file. ESXi often splits a disk into a small descriptor file and a large data file ending in -flat.vmdk. You need to point the conversion tool at the -flat.vmdk file, or ensure both files are in the same directory.
• Check available disk space. A thin-provisioned VMDK can expand significantly during conversion. Make sure the destination drive has enough space for both the original VMDK and the output QCOW2 file.
• Shut down the VM cleanly. Never convert a disk from a running or suspended VM. A full guest shutdown ensures the filesystem is in a consistent state with no dirty writes remaining.

How to Convert VMDK to QCOW2 on Linux (qemu-img)

The most straightforward way to convert disk formats on Linux is with the qemu-img utility, part of the QEMU toolset.

Step 1: Install qemu-utils

Most Linux distributions do not include qemu-img by default. Install it with the package manager for your distribution.

For Ubuntu or Debian:

sudo apt update && sudo apt install qemu-utils

For RHEL, CentOS, or Fedora:

# RHEL/CentOS 7
sudo yum install qemu-img

# RHEL/CentOS 8+, Fedora
sudo dnf install qemu-img

Step 2: Run the conversion command

Navigate to the directory containing your source VMDK, then run:

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

The flags work as follows:

• -f vmdk: specifies the input format
• -O qcow2: specifies the output format
• -p: (optional) displays a progress bar during conversion
• -c: (optional) compresses the output to reduce file size

Step 3: Verify the output

Once the conversion finishes, confirm the output file is valid:

qemu-img info output.qcow2

This returns the virtual size, actual disk usage, and format type. If the format shows qcow2 and the virtual size matches your original disk, the conversion succeeded.

Step 4: Handle Windows guest drivers

If the source VM runs Windows, it will likely fail to boot on KVM after conversion. Windows does not include VirtIO drivers by default, so it cannot communicate with the KVM storage controller.

There are two ways to handle this:

• Before migration: install the VirtIO guest tools inside the Windows VM while it is still running on VMware, then convert and import.
• After migration: when creating the new KVM VM, set the disk bus to IDE instead of VirtIO SCSI. Windows can boot using its built-in IDE driver. Once the VM is running, install the VirtIO Windows drivers from the official Red Hat repository and then switch the disk controller to VirtIO SCSI.

How to Convert VMDK to QCOW2 on Proxmox

Proxmox VE is based on Debian and comes with qemu-img pre-installed. However, the import workflow is different from a standard Linux conversion. Simply copying a .qcow2 file into a storage directory will not work — Proxmox manages disks through its own configuration system, and disks need to be registered properly using qm importdisk.

Step 1: Perform the conversion

Upload your VMDK to the Proxmox host (via SCP or the web UI file upload) and run the conversion:

sqemu-img convert -f vmdk -O qcow2 source.vmdk output.qcow2

Step 2: Import the disk to a VM

Once converted, import the QCOW2 file into a specific VM using qm importdisk:

qm importdisk <VMID> output.qcow2 <storage_name>

Replace <VMID> with your target VM number (e.g., 101) and <storage_name> with your Proxmox storage target (e.g., local or local-lvm).

After the import completes, go to the VM’s Hardware tab in the Proxmox web UI and attach the newly imported disk before booting.

Storage Format Restrictions

Not all Proxmox storage backends support QCOW2 files directly.

• Directory-based storage (such as local, which stores files under /var/lib/vz): supports .qcow2 files natively.
• Block-based storage (such as local-lvm or ZFS): does not store QCOW2 files. When you run qm importdisk targeting one of these backends, Proxmox automatically extracts the data and writes it as a raw logical volume. This is expected behavior and generally delivers better I/O performance.

How to Convert VMDK to QCOW2 on Windows

qemu-img is not available as a native Windows application. The most reliable approach is to run it through the Windows Subsystem for Linux (WSL), which gives you a full Linux environment without the overhead of a separate VM.

Step 1: Enable WSL and install Ubuntu

Open PowerShell as an administrator and run:

wsl --install

This installs WSL 2 with Ubuntu as the default distribution. A restart is required to complete the setup. Once your machine reboots, a terminal window will open to finish the Ubuntu installation.

Step 2: Install qemu-utils inside WSL

In your Ubuntu terminal, run:

sudo apt update && sudo apt install qemu-utils

Step 3: Copy your VMDK into the WSL filesystem

WSL mounts your Windows drives under /mnt/. A file at C:\VMs\my_disk.vmdk is accessible in WSL at /mnt/c/VMs/my_disk.vmdk.

However, running the conversion directly on a /mnt/c/ path is significantly slower due to cross-filesystem overhead. For better performance, copy the VMDK into the WSL home directory first:

cp /mnt/c/VMs/my_disk.vmdk ~/my_disk.vmdk
cd ~

Step 4: Run the conversion

qemu-img convert -f vmdk -O qcow2 my_disk.vmdk output.qcow2

Step 5: Move the output back to Windows

Once the conversion finishes, copy the QCOW2 file back to your Windows drive:

cp ~/output.qcow2 /mnt/c/VMs/output.qcow2

The file is then accessible in Windows Explorer and ready to transfer to your KVM or Proxmox host.

Convert VMDK to QCOW2 with virt-v2v

qemu-img only converts the disk format. It does not touch the operating system inside the disk. When migrating a Windows VM from ESXi to KVM, the guest will often fail to boot because it lacks the VirtIO drivers required by the new hypervisor.

virt-v2v solves this by handling the full migration in a single step. It converts the disk format, injects VirtIO storage and network drivers, adjusts the bootloader, and removes VMware Tools to prevent conflicts.

When to use virt-v2v instead of qemu-img

Use virt-v2v when:

• The source VM runs Windows and manual driver installation is not practical
• You want to migrate directly from a live ESXi or vCenter host rather than working with exported files
• You need the guest OS reconfigured automatically for the new hypervisor environment

For Linux guests, qemu-img is usually sufficient. Linux kernels include VirtIO drivers by default, so a format-only conversion typically works without boot issues. If you are evaluating other V2V conversion tools beyond the command line, our guide covers the main options.

Basic virt-v2v usage

virt-v2v is available on most Linux distributions via the package manager:

# Debian/Ubuntu
sudo apt install virt-v2v

# RHEL/CentOS/Fedora
sudo dnf install virt-v2v

To migrate a VM directly from a vCenter server:

virt-v2v -ic vpx://user@vcenter.example.com/Datacenter/esxi-host \
  -it vddk \
  -o local -os /var/tmp \
  my_windows_vm

To connect to a standalone ESXi host instead, replace vpx:// with esx://:

virt-v2v -ic esx://user@esxi-host.example.com \
  -it vddk \
  -o local -os /var/tmp \
  my_windows_vm

The tool outputs a converted QCOW2 disk and a .xml metadata file to the specified directory. These can then be imported into KVM or Proxmox.

VMDK to QCOW2 Conversion Troubleshooting: Common Errors & Fixes

Most conversion issues come down to two things: selecting the wrong source file, or a mismatch between the hardware configuration the guest OS expects and what KVM provides.

The table below covers the most common errors and how to fix them.

Simplify VMDK to QCOW2 Migration with i2Migration

The qemu-img and virt-v2v workflows covered in this guide work well for individual conversions. But when you are migrating multiple VMs across environments — or need to keep production systems running throughout the process — manual command-line tools start to show their limits. There is no built-in validation, no centralized progress tracking, and no way to handle a failed transfer mid-stream without starting over.

i2Migration is a unified migration platform built for exactly these scenarios. It supports live, non-disruptive migration across physical, virtual, and cloud environments, and addresses several of the pain points that come up during a VMware-to-KVM transition at scale.

Key Features of i2Migration:

• Zero-downtime migration: i2Migration uses hybrid block-level and file-level replication to migrate systems without shutting down production workloads, removing the requirement to export and convert offline.
• BIOS/UEFI conversion and driver injection: For Windows guests — where boot failures after format conversion are a common issue — i2Migration handles driver injection and firmware conversion automatically to ensure the migrated system boots correctly in the new environment.
• Cross-environment coverage: Supports P2V, V2V, physical-to-cloud, and virtual-to-cloud migrations, making it applicable beyond VMware-to-KVM moves.
• Built-in validation: Performs end-to-end dataset validation with automatic correction, so you are not manually running qemu-img info to verify each disk after conversion.
• Secure transfer: Combines AES/SM4 encryption, bandwidth control, parallel transmission, and resume-from-breakpoint for reliable transfers over long distances or unstable connections.

For teams that also need ongoing data protection after the migration is complete, i2Backup provides centralized backup across virtual, physical, and cloud environments. For workloads with stricter availability requirements, i2Availability handles real-time replication and automatic failover between production and disaster recovery environments.

Conclusion

Converting a VMDK to QCOW2 comes down to choosing the right tool for the job.

For most Linux users, qemu-img handles the conversion cleanly in a few commands. On Proxmox, the additional qm importdisk step is required to register the disk correctly with the storage backend. Windows users can follow the same Linux workflow through WSL. When migrating Windows guests from ESXi where driver reconfiguration is needed, virt-v2v is the more reliable choice over a format-only conversion.

Whichever method you use, the same rules apply: commit all snapshots before exporting, point the tool at the -flat.vmdk data file, and verify the output with qemu-img info before importing.

For teams handling larger-scale migrations or workloads that cannot tolerate downtime, i2Migration by Info2soft provides a more structured path with built-in validation, driver injection, and live migration support across heterogeneous environments.