Table of Contents
Choosing between the RAW and QCOW2 disk image formats affects performance, storage efficiency, snapshots, and backups in KVM-based environments — VMware alternatives like OpenStack and Proxmox included. With so many organizations migrating off VMware and converting VMDK disks to one of these formats, the choice is more relevant than ever. This guide compares them accurately and shows when to use each.
What is a RAW image?
A RAW image is a plain, unstructured disk image — a direct, byte-for-byte representation of a disk, with no metadata layer. That simplicity is its strength:
- Performance. With no format overhead, RAW delivers the highest potential I/O, close to the underlying device — ideal for databases, HPC, and other performance-critical workloads.
- Simplicity and portability. A plain disk image is easy to mount, inspect, recover, and convert to other formats.
- Works natively with block storage. RAW is the natural fit for LVM volumes, Ceph RBD, and ZFS zvols.
A common misconception is that RAW always wastes space by occupying its full allocated size. That’s only true for a fully preallocated image. Created as a sparse file, a RAW image consumes only the blocks actually written — a fresh sparse 100 GB image might use just a few GB. The caveat: sparseness depends on the host file system, and some copy or migration tools “inflate” a sparse image to its full size unless they preserve sparse allocation.
RAW’s main limitation is that it has no internal snapshot mechanism. In production, snapshots for RAW come from the storage layer (LVM, Ceph RBD, ZFS, Btrfs) rather than the format itself.
What is a QCOW2 image?
QCOW2 (QEMU Copy-On-Write, version 2) is QEMU’s native format, adding a feature layer on top of the raw data:
- Thin provisioning. QCOW2 allocates space in clusters (typically 64 KB) only as the guest writes, so the file grows on demand. This — not compression — is the main reason a QCOW2 image is usually smaller than a fully-allocated RAW one.
- Internal snapshots. QCOW2 supports multiple point-in-time snapshots within the file itself.
- Backing files. A QCOW2 overlay can record only the changes from a base image, leaving the original untouched — the basis for templates and linked clones.
- Optional compression and encryption. QCOW2 can compress clusters (typically for read-only template images — compressed clusters can’t be rewritten in place, so it isn’t a default) and supports LUKS encryption.
The trade-off is a small performance overhead: QCOW2 walks a two-level (L1/L2) index to map clusters, adding latency that’s negligible for sequential I/O but more noticeable under heavy random workloads. With tuning (and preallocation of metadata), QCOW2 can come close to RAW performance.
RAW vs. QCOW2 at a glance
| RAW | QCOW2 | |
|---|---|---|
| Structure | Plain disk image | Layered format with metadata |
| Performance | Highest, near-native | Slight overhead (index lookups) |
| Space efficiency | Sparse files (filesystem-dependent) | Thin provisioning (built-in) |
| Internal snapshots | No (use storage layer) | Yes |
| Backing files / linked clones | No | Yes |
| Compression / encryption | No (native) | Optional |
| Best storage fit | Block: LVM, Ceph RBD, ZFS | File/directory-based storage |
| Portability | Very high | High |
Which should you use?
Choose RAW when raw performance is the priority, or when your storage layer already provides thin provisioning, snapshots, and cloning. On Ceph RBD, LVM, or ZFS, RAW is usually the right choice — the storage handles those features, so putting QCOW2 on top is redundant and can hurt performance.
Choose QCOW2 when you’re on file/directory-based storage and want the format itself to provide thin provisioning, snapshots, backing files, or encryption — a common, convenient setup in KVM and Proxmox directory storage.
In short: let the storage decide. Block/object storage → RAW; file-based storage → QCOW2.
A note on migration
When moving VMs off VMware, their VMDK disks are converted to RAW or QCOW2 for KVM-based targets like OpenStack and Proxmox (tools such as qemu-img and virt-v2v handle this). Match the target format to the destination storage using the guidance above, and watch for sparse-file inflation during conversion — preserving thin allocation keeps the migrated image from ballooning to full size.
How Storware supports RAW and QCOW2
Storware Backup and Recovery protects KVM-based virtual machines — across OpenStack, Proxmox VE, Oracle Linux VM, and other KVM environments — handling both RAW and QCOW2 disks, including Ceph RBD-backed volumes. And with cross-platform V2V migration into OpenStack (in version 7.5), it uses the same backup engine to move VMs from VMware and other hypervisors — format conversion included — under a single universal license. Learn more.
Ready to protect your data?
Conclusion
RAW and QCOW2 both have a clear place in KVM, OpenStack, and Proxmox environments. RAW gives you maximum performance and simplicity and pairs naturally with block storage that provides its own snapshots; QCOW2 brings built-in thin provisioning, snapshots, backing files, and encryption, ideal on file-based storage. Match the format to your performance needs and — crucially — to your storage layer, and whichever you choose, make sure those VMs are backed up.
