Converting VMDK to QCOW2 is one of the most commonly performed processes when performing KVM migrations. The QCOW2 format has features like snapshots and thin provisioning, which are common in VMware platforms. For this reason alone, QCOW2 is a popular destination format when moving workloads from systems that use VMDK disks.
In a real-world scenario, virtual machine migrations involve more than just converting disk files to images. You also have to make sure to preserve VM metadata, which is important when running and migrating workloads over different platforms.
This article shows you how to convert VMDK disks to QCOW2 using common tools. It also covers how disk conversion fits into the overall migration process. You will also learn practical commands, best practices, and advice for choosing the best method for different platforms.
Summary of key aspects to consider when converting VMDK to QCOW2
| Aspect | Description |
|---|---|
| VMDK structure and integrity | Understanding the VMDK layout and verifying disk integrity ensures successful conversion and helps you identify potential issues before migration begins. |
| Conversion flags and options | Selecting appropriate flags for compression, preallocation, and cluster size allows you to optimize the balance between performance, disk size, and compatibility with the target environment. |
| Disk optimization strategies | Applying post-conversion techniques such as sparsification and resizing lets you reclaim unused space and adjust disk allocations to match workload requirements. |
| Validation and testing | Conducting boot tests, integrity checks, and real-world workload simulations confirms that converted VMs function correctly and perform as expected in the target environment. |
| Steps after disk conversion | Migrating VM metadata, network configurations, and platform constructs alongside disk images ensures that workloads achieve full operational parity in OpenStack or OpenShift virtualization. |
Overview of converting VMDK to QCOW2
A successful conversion depends on understanding how the source VMDK is structured, because conversion tools must correctly interpret VMware disk metadata and data extents. The VMDK format separates metadata from raw disk data, and conversion tools rely on this structure to reconstruct the disk correctly in the QCOW2 format.
For example, a monolithicFlat VMDK has a small <disk>.vmdk descriptor file that points to a <disk>-flat.vmdk. During conversion, qemu-img reads the descriptor file to locate the correct data extents, making it mandatory for an accurate QCOW2 output.
Automated OpenStack & OpenShift Data Protection & Intelligent Recovery
Enjoy native OpenStack integration, documented RESTful API, and native OpenStack CLI
Restore Virtual Machines with Trilio’s One-Click Restore
Select components of your build to recover via the OpenStack dashboard or CLI
Architecture diagram of a monolithicFlat VMDK (source)
Before performing any conversion, the VMDK should be inspected to confirm that the file is readable and internally consistent. This is done using qemu-img info vm.vmdk. From a conversion perspective, this step ensures that qemu-img can correctly resolve the disk structure before attempting to translate it into QCOW2 format.
Snapshot chains directly affect which data is converted and must be handled correctly to avoid producing an outdated QCOW2 image. During conversion, only the active tip of the snapshot chain must be selected; otherwise, the resulting QCOW2 image may not reflect the VM’s current state.
Learn how Trilio’s partnership with Canonical helps better protect your data
Overview of VM snapshots in VMware vSphere (source)
Because conversion tools depend entirely on the integrity of the VMDK chain, broken parent-child links can result in silent data loss in the QCOW2 image. VMDKs should always be backed up prior to conversion, and checksums should be computed on both the source VMDK and the converted QCOW2 image to validate data integrity.
Preparing your environment
Set up a Linux host with the necessary tools and a staging area:
- Install conversion tools: At minimum, install QEMU utilities using yum or apt.
# RHEL or CentOS yum install qemu-img # Debian/Ubuntu apt install qemu-img
For automated conversion, install the virt-v2v utility to handle metadata and drivers. For example, Red Hat’s Virtualization package provides virt-v2v for VMware to KVM migration. Ensure that your user is a member of the libvirt or kvm group (or run as root) to access disk files. Here are some details to pay attention to:
- Working directory: Since the raw disk can be as large as the source, choose a directory with the most significant amount of free space. If your VMDK is split, copy both the descriptor and extent files together. If you have an exported OVA, extract the OVA file to obtain the .vmdk file. Check permissions so qemu-img can read the descriptor and all extent files.
- Network and storage: For full migrations, ensure network access between the VMware source, the conversion host, and the target. If using Ceph or another backend (e.g., OpenStack RBD), have the Ceph/RBD client tools installed (or run via cephadm shell). Otherwise, prepare a local or NFS folder to hold the converted QCOW2 or raw image.
Learn about the features that power Trilio’s intelligent backup and restore
Running the conversion
QEMU options
The core tool to use is qemu-img convert. Here are some of the important flags of this tool:
- Format flags: Use -f vmdk and -O qcow2 (or -O raw) to set source and target formats. For example:
qemu-img convert -p -f vmdk -O qcow2 source_vm.vmdk target_vm.qcow2Here -p shows progress. The -f (source format) is optional if QEMU can auto-detect it, while -O (output format) should be explicitly specified; if omitted, it defaults to raw format. As QCOW2 supports both snapshots and compression, it is often an ideal choice for virtualization environments. Raw (-O raw) yields the fastest, simplest disk at the expense of a larger size.
- Compression (-c): QCOW2 supports on-the-fly compression with -c. This saves space but makes subsequent writes slower. (Only the QCOW and QCOW2 formats support -c.) Compressed QCOW2 is read-only compression, meaning overwritten sectors decompress automatically. For a test VM or archive, -c is useful; for a high-I/O production disk, skip it.
- Sparse writing: By default, qemu-img convert will skip writing long runs of zeros in the output (sparse allocation). You can control this with -S bytes (the zero-run threshold). For example, -S 1M makes any 1 MiB+ of zeros skip writing. This keeps QCOW2/RBD images smaller by not allocating empty space.
- Preallocation: QCOW2’s metadata can be preallocated for better performance on growth. Using -o preallocation=metadata makes the target image initially bigger (it pre-writes its metadata tables) but can speed up future writes.
- Additional options: For very fast copying (e.g. to a Ceph RBD), you could also use -o backing_file or rbd import as shown in OpenMetal’s examples, but the basic CLI approach is as above.
Note: Always run qemu-img convert offline (with the VM powered off or the disk detached), otherwise the output may be inconsistent.
Example conversions
Test VM (small, non-critical): A simple conversion might be:
qemu-img convert -p -f vmdk -O qcow2 test-vm.vmdk test-vm.qcow2
This auto-detects formats and shows progress. The resulting test-vm.qcow2 will be a dynamic QCOW2 image.
Production VM (medium size): To minimize runtime and tune performance, include flags. For instance:
qemu-img convert -p -f vmdk -O qcow2 -o preallocation=metadata centos-db.vmdk centos-db.qcow2High-IOPS VM: If performance is critical, convert to raw:
qemu-img convert -p -f vmdk -O raw fast-vm.vmdk fast-vm.rawUsing RAW gives minimal overhead on the hypervisor (especially in Ceph/RBD), at the cost of larger file size. For example, OpenMetal’s workflow uses raw targets for high-performance DB migration. (You could also do QCOW2 with large cluster or preallocation=full, but raw is simplest for peak throughput.)
Each example above must be adapted to your environment (paths, tools). Always verify the result using the command qemu-img info. Lastly, during a production cutover, boot the VM in a test environment before switching.
All in all, always validate the converted VM (boot it and verify data) and keep the original VMDKs until you’re certain the migration succeeded.
How everything fits into the bigger picture
Remember that disk conversion is only the first step of the process, as you still have to move the VM’s metadata with it. In this article, we mainly discuss converting VMDKs, but there are methods that convert the whole VM easily:
- Disk-only migration: This method converts the virtual disk and can add KVM drivers, but it does not create a working VM on the target. Networking and compute settings (metadata) are lost in a raw disk image. Administrators must manually set the VM name, vCPU, RAM, network cards, and storage controllers in the new environment.
- Full migration tools: Automated workflows (like Trilio or MTV) can also handle the conversion steps presented in the previous section. They discover source VMs, map VMware concepts to the target, create VM placeholders, and transfer both data and config. For example, Red Hat’s Migration Toolkit for Virtualization (MTV) lets you define a NetworkMap (vSphere port group → KubeVirt network) and StorageMap (vSphere datastore → OpenShift/KubeVirt storage class), so that when it runs a migration plan, it automatically imports the disks and creates KubeVirt VirtualMachine objects with the correct specs.
This means disk conversion is only one piece of the puzzle. The VM’s set of metadata—its name, flavor (CPU/RAM quota), NIC models, network subnets, security groups, and other attributes—is equally critical for integration. OpenStack, OpenShift (KubeVirt), and similar clouds require a fully specified VM instance (often via a “flavor” or InstanceType) to run a VM. A bare disk image carries none of this.
Tools like Trilio explicitly extract VMware VM metadata and use it to build matching VMs on the target. Likewise, Red Hat MTV uses virt-v2v to collect metadata about VMs during migration. However, MTV only populates that metadata into new KubeVirt VM definitions, not into the raw disk file itself.
The kubevirt architecture (source)
Shown above is an example of a full-stack migration solution that handles both data and metadata end to end.
Trilio for VMware to OpenStack (TrilioVault/Trilio for Openstack – T4O) Scenario
Trilio provides an OpenStack-native, agentless workflow that handles both disk conversion and VM metadata reconstruction. The migration process typically follows these steps:
- Source VM discovery and metadata extraction: Trilio connects to vCenter and discovers VMware workloads, collecting both disk data and associated VM metadata such as CPU, memory, network configuration, and storage layout.
- Migration planning and placeholder VM creation: During the planning phase, Trilio creates placeholder virtual machines in OpenStack. These placeholder instances are defined with matching flavors (vCPU and RAM), target networks, security groups, and empty Cinder volumes that correspond to the source VMware disks.
- Network and storage mapping: VMware constructs are mapped to OpenStack equivalents. VMware port groups are mapped to OpenStack subnets, and vSphere datastores are mapped to appropriate Cinder volume types, ensuring compatibility with the target cloud architecture.
- Disk data transfer and conversion: Trilio’s Data Mover, leveraging virt-v2v, copies disk blocks from the VMware environment into the provisioned OpenStack volumes. This step performs the underlying VMDK-to-QCOW2 (or raw) conversion while preserving data integrity.
- Validation and iterative dry runs: Placeholder VMs can be boot-tested in OpenStack before final cutover. If adjustments are required, mappings and configurations can be refined and revalidated through repeated dry runs.
- Final VM instantiation on OpenStack: Once validated, the migration produces fully functional OpenStack instances with correctly configured compute resources, networking, storage attachments, and security policies, rather than just converted disk images.
Disk-image conversion is only a part of any VMware to KVM migration. Full migrations require re-establishing the VM’s context in the new environment. Tools like Trilio automate that context by importing VM definitions and configurations, mapping networks/storage, and then plugging in the converted disk image.
More details about how Trilio can help with VMware Migration to OpenStack can be found here: https://trilio.io/products/vmware-to-openstack-migration/
Find out how Vericast solved K8s backup and recovery with Trilio
Final thoughts
While converting VMDK to QCOW2 is easy and reliable, this is only one of the first steps that you will take to migrate and cut over your system running VMware. Ensure that metadata is also prepared and transferred over to the new system to avoid issues in the long run.
Additionally, there is always a risk of issues and corruption, especially when dealing with VMs that host live and production-level workloads. Ensure that your data is protected from potential loss and corruption, and back up your VMs before attempting any critical operations.
Ready to eliminate migration risk and downtime? Schedule a demo to watch how Trilio guarantees data integrity and instant rollback capability for your most critical workloads.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content