How to Convert and Resize Virtual Machine Disk Images in Linux Using qemu-img

Managing virtual machine disks often requires converting storage formats when migrating workloads between hypervisors or expanding storage capacity as guest filesystems grow. Whether you are migrating VMware Workstation disks (.vmdk) to Proxmox VE, converting VirtualBox images (.vdi) to QEMU/KVM, or deploying compressed cloud images (.qcow2), the qemu-img utility provides the fastest and most reliable command-line tool in Linux for manipulating disk images offline.

In this tutorial, we will explore how to install qemu-img, inspect virtual drive metadata, convert between major virtualisation formats with compression, resize virtual disk capacities, and verify image integrity before booting your hypervisors.

Installing the qemu-img Utility Across Linux Distributions

The qemu-img command is packaged as part of the QEMU emulator tools. Depending on your Linux distribution, install the appropriate package via your package manager:

On Ubuntu, Debian, and Linux Mint:

sudo apt update
sudo apt install qemu-utils -y

On Fedora, RHEL, Rocky Linux, and AlmaLinux:

sudo dnf install qemu-img -y

On Arch Linux and Manjaro:

sudo pacman -S qemu-tools

Once installed, verify the binary by checking its version string:

qemu-img --version

Inspecting Disk Image Metadata with qemu-img info

Before modifying or converting a disk, inspect its format, virtual capacity, actual physical disk consumption, and cluster size:

qemu-img info /var/lib/libvirt/images/ubuntu-server.qcow2

The command outputs a structured summary similar to the following:

image: /var/lib/libvirt/images/ubuntu-server.qcow2
file format: qcow2
virtual size: 50 GiB (53687091200 bytes)
disk size: 6.42 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Notice the distinction between virtual size (the capacity reported inside the guest OS) and disk size (the actual host storage consumed due to sparse allocation).

Converting Virtual Disk Formats

The convert sub-command reads an input image and outputs a completely new file formatted for your target hypervisor. The original source image remains completely untouched.

1. Converting VMware VMDK to KVM QCOW2

To import a virtual machine exported from VMware ESXi or Workstation into KVM, libvirt, or Proxmox, convert the .vmdk disk into a modern copy-on-write .qcow2 container:

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

The flags used here standardise the conversion workflow:

• -p: Displays a real-time percentage progress bar during conversion.
• -f vmdk: Explicitly defines the input source format.
• -O qcow2: Specifies the target output format (capital letter ‘O’).

2. Converting VirtualBox VDI to QCOW2 with Compression

If you are transferring a VirtualBox .vdi image to a home server running Linux KVM, you can simultaneously convert and compress the data blocks using the -c flag:

qemu-img convert -p -c -f vdi -O qcow2 virtualbox-vm.vdi kvm-disk.qcow2

Applying the -c compression flag instructs qemu-img to compress unallocated or repetitive clusters using zlib, often reducing image footprint by 40% to 60% with negligible decompression overhead during guest reads.

3. Converting RAW Disk Images to Sparse QCOW2

RAW images offer exceptional input/output speed but consume the entirety of their provisioned disk space immediately. Converting a RAW image to QCOW2 reclaims unused space:

qemu-img convert -p -f raw -O qcow2 disk.raw disk.qcow2

Resizing Virtual Machine Disks with qemu-img resize

When a virtual machine runs out of root or database storage, you must first expand the virtual disk file on the host before expanding the partitions and filesystems inside the guest operating system.

Crucial Safety Rule: Always shut down the virtual machine completely before executing the resize command. Modifying a running disk image causes severe filesystem corruption.

Expanding Disk Capacity

To increase a virtual disk’s capacity by an additional 25 Gigabytes, use the relative addition operator (+):

qemu-img resize disk.qcow2 +25G

Alternatively, set an absolute target size (for instance, setting the disk to exactly 100GB):

qemu-img resize disk.qcow2 100G

After resizing the host image file, power on the guest operating system and use utilities such as growpart, fdisk, and resize2fs (for ext4) or xfs_growfs (for XFS) to expand the guest filesystem into the newly provisioned space.

Creating Fresh Sparse Disk Images

If you are provisioning a brand new virtual machine from scratch using CLI hypervisors like virsh, qemu-system-x86_64, or custom containers, use the create sub-command:

qemu-img create -f qcow2 -o preallocation=metadata /var/lib/libvirt/images/web-server.qcow2 40G

The preallocation=metadata option allocates internal QCOW2 tracking structures upfront while keeping the underlying data blocks sparse, delivering improved write throughput during initial guest OS installation.

Verifying and Repairing Corrupted QCOW2 Disk Images

In the event of an abrupt host power failure or hard system lockup, QCOW2 reference counts and cluster allocations can fall out of synchronisation. Use the check sub-command to audit and repair metadata tables:

qemu-img check -r all corrupted-vm.qcow2

The -r all argument instructs qemu-img to fix both reference count leaks and cluster overlaps, restoring filesystem bootability without needing manual hex-editor intervention.

Operational Best Practices for Hypervisor Storage

To maintain peak performance and data resilience when administering virtual disks in production environments, implement these operational practices:

• Avoid Shrinking Disks In Place: While qemu-img resize --shrink exists, reducing disk capacity from the outside without meticulously shrinking the guest partition table first will truncate filesystems and cause catastrophic data loss.
• Ensure Adequate Free Disk Space: During image conversion, both the source and target files exist concurrently on the host filesystem. Ensure your host volume has at least 120% of the virtual disk size available before commencing conversion.
• Utilise Solid-State Storage for Conversions: Sequential disk writes during image conversions benefit dramatically from NVMe or SSD storage tiers, completing multiterabyte migrations in minutes rather than hours.