qcow2 vs raw, and How Snapshots Work

Introduction¶

A KVM disk image is a file (or block device) the guest sees as a disk. The two main formats are raw and qcow2, and the choice affects performance, space, and whether you can snapshot.

raw¶

Just the disk bytes, 1:1. A 40GB disk is a 40GB file (or a sparse file that grows as written).

• Fastest — no format layer, direct I/O.
• Works on any block device / LVM volume.
• No snapshots, no compression, no backing files at the format level (you can still snapshot via LVM/ZFS/btrfs underneath).
• Easy to inspect/convert; dd-friendly.

Use raw for: performance-critical VMs, when the storage layer (LVM thin, ZFS, Ceph RBD) provides snapshots and thin provisioning.

qcow2¶

QEMU Copy-On-Write v2 — a container format with a lot of features.

• Thin provisioning — a 40GB disk starts at ~200KB, grows on write.
• Internal snapshots — multiple point-in-time states in one file.
• Backing files — an image can be based on another (read-only) image; writes go to the overlay only.
• Compression (-c at creation/convert), encryption (LUKS).
• Slight overhead vs raw (a few %), mitigated by a large cluster_size and cache=none.

qemu-img create -f qcow2 -o preallocation=metadata,cluster_size=64k vm.qcow2 40G
qemu-img info vm.qcow2

Backing files (copy-on-write templates)¶

# golden image: base.qcow2 (a prepared template)
qemu-img create -f qcow2 -F qcow2 -b base.qcow2 vm1.qcow2
qemu-img create -f qcow2 -F qcow2 -b base.qcow2 vm2.qcow2

vm1.qcow2 only stores what differs from base.qcow2. Ten VMs from one template share the base's blocks on disk. Never modify base.qcow2 while overlays depend on it — you'll corrupt them. To bake changes in later: qemu-img rebase / qemu-img commit.

Snapshots¶

Internal (qcow2 only)¶

Stored inside the qcow2 file:

virsh snapshot-create-as vm snap1 "before upgrade" --disk-only --atomic
virsh snapshot-list vm
virsh snapshot-revert vm snap1
virsh snapshot-delete vm snap1
# offline / qemu-img:
qemu-img snapshot -l vm.qcow2
qemu-img snapshot -c snap1 vm.qcow2

Simple (one file), but reverting is slow-ish and the file only grows. Not supported on raw.

External¶

The current image becomes a read-only backing file; a new overlay captures future writes:

virsh snapshot-create-as vm snap1 \
  --diskspec vda,snapshot=external,file=/images/vm.snap1.qcow2 \
  --disk-only --atomic --no-metadata

Now vm.snap1.qcow2 (backing = vm.qcow2) is live. This is the basis of live backups: snapshot externally, copy the now-read-only base, then blockcommit the overlay back:

virsh blockcommit vm vda --active --pivot --verbose

blockcommit merges the overlay into the base while the VM runs, then pivots the VM onto the base. External snapshots + blockcommit is how oVirt/Proxmox do online backups.

Full memory + disk snapshot (running VM)¶

virsh snapshot-create-as vm full1 --memspec file=/images/vm.mem,snapshot=external \
  --diskspec vda,snapshot=external,file=/images/vm.d1.qcow2

Captures RAM too — revert returns the VM to the exact running state. Larger and slower; use for "I'm about to do something risky right now".

Reclaiming space¶

qcow2 files grow and don't shrink when the guest deletes data — unless:

# In the guest (needs virtio-scsi + discard='unmap'):
fstrim -av

# Offline compaction:
qemu-img convert -O qcow2 -c bloated.qcow2 compact.qcow2   # -c also compresses
virt-sparsify --in-place vm.qcow2

Verification and troubleshooting¶

qemu-img info --backing-chain vm.qcow2      # the full overlay chain
qemu-img check vm.qcow2                       # consistency check (offline)
virsh domblklist vm                           # which file the VM is actually using

• VM won't boot after deleting a snapshot / base image — you removed a file still in the backing chain. qemu-img info --backing-chain before deleting anything. A missing backing file is usually unrecoverable.
• Disk full on the host, VM paused — a qcow2 grew into all free space, or external snapshot overlays accumulated. blockcommit / delete old snapshots; monitor qemu-img info disk size.
• qemu-img: Could not open ... Image is not in qcow2 format — it's raw, or corrupt. qemu-img info reports the real format; file vm.img.
• Snapshot revert did nothing / VM state wrong — internal disk-only snapshot doesn't restore RAM; you reverted to the disk state but the VM kept its memory. Use --memspec for full snapshots, or shut down before reverting.
• Slow qcow2 performance — cache=none + io=native (or threads), cluster_size=64k, preallocation for write-heavy VMs, and don't stack it on a network filesystem. Or switch that VM to raw on LVM.
• fstrim frees nothing — guest disk is virtio-blk (no discard) or the libvirt XML lacks discard='unmap'; and the host filesystem must support hole-punching.

Related tools and reading¶

• On-site: Linux commands reference.
• Related posts: virtio drivers explained, KVM and libvirt: your first VM.