Information2 use cookies to help you have a superior and more admissible browsing experience on our website. Privacy Policy
Loading...
By:
When deploying virtual machines in KVM or QEMU, the choice of virtual disk format comes up early. In most cases, it comes down to raw and QCOW2. Both support the same guest operating systems, but raw prioritizes I/O performance while QCOW2 trades a small overhead for features like snapshots, thin provisioning, and compression.
The format you choose affects VM performance, disk space usage, backup workflows, and day-to-day management. This guide breaks down the differences and helps you pick the right one for your workload.
To choose between the two formats, it helps to understand how each one stores and manages virtual disk data on the host.
A raw disk image is the simplest virtual disk format in KVM/QEMU. It stores the exact sector-by-sector contents of a virtual disk with no added structure or metadata layer.
How Raw Images Work
Raw images map virtual disk blocks directly to host storage. There is no internal metadata, no block index, and no snapshot table. When a VM writes data, the hypervisor passes it straight through to the corresponding location on disk, which is why raw images deliver near-native I/O performance.
Sparse File Behavior
Raw images are not always fully allocated. When created as a sparse file, the image only consumes physical space as the guest writes data. A 100 GB sparse raw image might occupy just 5 GB after a fresh OS install.
One caveat: some copy tools fill empty blocks with real data during migration, expanding the image to its full virtual size on the destination.
QCOW2 (QEMU Copy-On-Write version 2) is the native disk image format for QEMU. Unlike raw, it trades a small performance overhead for built-in snapshots, thin provisioning, compression, encryption, and backing file support.
Copy-on-Write Architecture and Cluster Allocation
QCOW2 organizes data into 64 KB clusters and only allocates physical storage when the guest writes to a cluster. This means the image grows on demand rather than consuming its full provisioned size upfront.
Backing files work the same way: QCOW2 records only the changes from the base image, leaving the original untouched. This makes it the standard choice for VM templates and linked clones.
The L1/L2 Table Lookup Mechanism
QCOW2 uses a two-level index — an L1 table pointing to L2 tables, which then map to the actual data clusters. Every read or write requires walking this index before reaching the data, which adds latency compared to raw’s direct block mapping. The impact is small for sequential I/O but more noticeable under heavy random workloads.
The two formats approach storage differently. raw keeps things simple and fast; QCOW2 adds a feature layer on top. The table below summarizes the key differences.
| Feature | raw | QCOW2 |
|---|---|---|
| Primary Advantage | Maximum I/O performance | Advanced storage management |
| Storage Allocation | Fully allocated or sparse | Native thin provisioning |
| Native Snapshots | Not supported | Supported (internal and external) |
| Backing Files | Not supported | Supported |
| Native Encryption | Not supported | Supported (LUKS) |
| Native Compression | Not supported | Supported (zlib / zstd) |
Raw images can be created as sparse files, which gives basic thin provisioning at the file system level. The downside is that sparse behavior depends on the host file system and the tools used — some copy or backup utilities will fill empty blocks with real data during transfer, inflating the image to its full virtual size.
QCOW2 handles thin provisioning at the image level. QEMU manages cluster allocation directly, so the image grows on demand regardless of which host file system or transfer tool is used.
Raw images have no built-in snapshot support. Snapshots for raw-based VMs rely on external mechanisms such as LVM snapshots, Ceph snapshots, or storage array features.
QCOW2 supports both internal and external snapshots natively, and also supports backing files. Multiple VMs can share a single read-only base image and store only their individual changes in separate overlay files, which can significantly cut storage usage in large-scale deployments.
Raw has no native compression or encryption. These need to be handled at the host file system, storage platform, or guest OS level.
QCOW2 supports LUKS encryption and compression via zlib or zstd. Both are useful when archiving VM templates or maintaining golden images where storage efficiency matters.
Both formats support live migration between KVM hosts given the right shared storage or migration infrastructure. Raw may have a slight edge in migration overhead since it carries no metadata, but in practice, the difference is small, and network bandwidth is usually the bottleneck.
For online resize, both formats support expanding a virtual disk while the VM is running. QCOW2 updates its metadata automatically; raw relies on the underlying storage and guest tools to recognize the additional space.
Performance is one of the most common factors when choosing between raw and QCOW2. Raw has a structural advantage because it provides a simpler storage path, but the practical performance difference depends heavily on workload, storage backend, and configuration.
Under sequential workloads on preallocated storage, the performance difference between raw and QCOW2 is often small. Both formats can deliver similar throughput for read-heavy workloads or environments with moderate I/O demands.
The gap becomes more noticeable under scenarios such as:
Raw maps virtual disk blocks directly to host storage with no intermediate layer, keeping the I/O path as short as possible. QCOW2 adds processing at several points:
Under random write-heavy workloads, these factors compound and the latency difference compared with raw becomes more pronounced.
If you need QCOW2 features but want to reduce the performance gap compared with raw, several QEMU tuning options can help:
preallocation=metadata or preallocation=falloc): Reduces runtime allocation overhead by preparing metadata structures or allocating storage space during image creation.cache=none): Bypasses the host page cache to avoid double buffering between the guest and host. In some SSD-based environments, cache=writeback can improve throughput by grouping write operations.aio=native or aio=io_uring): Allows QEMU to process I/O requests more efficiently with reduced kernel overhead.l2-cache-size): Keeps more QCOW2 metadata tables in memory, reducing additional disk accesses during address translation.Raw’s performance advantage matters most for I/O-intensive workloads where storage latency directly affects application response times. Examples include high-transaction databases, busy message queues, and large-scale log processing systems.
For general-purpose virtual machines, development environments, and test labs, the performance difference is often small enough that QCOW2’s operational benefits (snapshots, thin provisioning, and backing files) provide greater value than the additional performance of raw.
Performance is only one factor. The right format depends on your storage architecture, operational workflows, backup strategy, and workload requirements.
Choose Raw if you:
Choose QCOW2 if you:
The best format depends on what you are running. Here is a breakdown by common scenario.
1. Database and High-I/O Workloads
For high-transaction databases like MySQL, Oracle, or PostgreSQL, raw is the safer default. If your storage layer already handles snapshots via LVM, Ceph, or a SAN, you get the performance benefit of raw without giving up snapshot capability.
2. General-Purpose VMs
QCOW2 works well here. Taking a snapshot before a system update and rolling back if something goes wrong is much simpler with QCOW2 than coordinating a storage-layer snapshot for a raw image.
3. VM Templates
QCOW2’s backing file mechanism lets multiple VMs share a single base image, with each instance storing only its own changes. This is not possible with raw without duplicating the full image for every VM.
4. Cloud Platforms
Most cloud platforms, including OpenStack, expect QCOW2 by default. Using raw may require format conversion before upload or deployment, adding an extra step to your workflow.
5. Test and Lab
The ability to snapshot, test, and roll back without touching external storage tooling is the main reason QCOW2 is the standard choice in lab setups.
If your storage strategy or platform requirements change, you can convert existing disk images using qemu-img, the standard QEMU utility for virtual disk management.
Shut down the VM before converting, or ensure the image is not being actively written to.
To convert raw to QCOW2:
qemu-img convert -f raw -O qcow2 source_image.raw destination_image.qcow2 -p
To convert QCOW2 to raw:
qemu-img convert -f qcow2 -O raw source_image.qcow2 destination_image.raw -p
Note that converting QCOW2 to raw can significantly increase the physical file size if the destination file system does not support sparse files.
When migrating between VMware and KVM environments, qemu-img handles VMDK-to-QCOW2 conversion as well.
To convert VMDK to QCOW2:
qemu-img convert -f vmdk -O qcow2 source_disk.vmdk destination_disk.qcow2 -p
To convert QCOW2 to VMDK:
qemu-img convert -f qcow2 -O vmdk source_disk.qcow2 destination_disk.vmdk -p
For Windows VMs, install VirtIO drivers before conversion. Without them, the VM may not boot after moving to a KVM environment.
Before attaching the converted image to a VM, run a quick check:
qemu-img info destination_image.qcow2
qemu-img check -f qcow2 destination_image.qcow2
qemu-img info shows the image format, virtual size, actual disk usage, and backing file configuration. qemu-img check validates QCOW2 metadata and reports issues such as leaked clusters or reference count errors.
Raw and QCOW2 require different backup approaches. The format you choose affects which tools and strategies are available to you.
Raw images have no built-in snapshot support, so backups depend on the storage or virtualization layer. For an offline backup, you can copy a powered-off image with dd:
dd if=source_image.raw of=/backup/destination_image.raw bs=1M status=progress
Copying a raw image while the VM is running risks an inconsistent backup. In production, use storage-level snapshots (LVM, Ceph, or SAN) or virtualization platform APIs to capture a consistent state without downtime.
QCOW2’s built-in snapshot support gives you more flexibility. External snapshots are generally preferred over internal ones in production because they are easier to manage and integrate with backup workflows.
QCOW2’s copy-on-write architecture also enables incremental backups: only changed data since the last snapshot needs to be captured, which reduces backup size and time.
Snapshots are useful for short-term protection but should not replace proper backups. As the chain grows, QEMU has to traverse more backing file layers to read data, which increases latency and degrades storage performance. Consolidate or remove snapshots regularly once they are no longer needed.
Manual backup workflows become harder to maintain as your VM environment grows. i2Backup automates this through agentless backup using native virtualization platform APIs, supporting both raw and QCOW2-based VMs.
Instead of full image copies each time, i2Backup uses block-level change tracking to capture only what has changed, reducing backup windows and storage consumption. For recovery, it supports instant VM recovery by mounting the backup image directly, as well as file-level restore for individual files or folders without recovering the entire VM.
Raw and QCOW2 serve different needs. Raw gives you a simpler I/O path and better performance under heavy workloads. QCOW2 trades a small overhead for snapshots, thin provisioning, and backing file support that make VM management easier day to day.
For most general-purpose deployments, QCOW2 is the practical default. For latency-sensitive workloads like high-transaction databases, raw is worth the trade-off, especially if your storage layer already handles snapshots independently.
Whichever format you use, make sure your backup strategy does not rely on snapshots alone. Snapshots are useful checkpoints, but they are not a substitute for proper, recoverable backups.
