A KVM virtual machine stores its disk either in a file or on a block device. The two common file formats are qcow2 vs raw, and the choice affects speed, disk usage and how snapshots work. This guide explains the differences and the storage options behind them.
Before you start
- A KVM host with
qemu-utils(Debian/Ubuntu) orqemu-img(RHEL family) installed. - Shut a VM down before converting or resizing its disk.
qcow2 vs raw at a glance
| qcow2 | raw | |
|---|---|---|
| Thin provisioning | Yes, grows as data is written | Sparse files only (filesystem dependent) |
| Internal snapshots | Yes | No |
| Backing files / linked clones | Yes | No |
| Compression and encryption | Optional | No |
| Performance | Very close to raw with preallocation=metadata | Fastest, no metadata layer |
| Portability | Good for copying and templates | Simple, readable by any tool |
When to use qcow2
- You want snapshots or templates with linked clones.
- You overcommit storage and want disks to grow only as used.
- You copy images between hosts and want them small.
When to use raw
- Maximum, predictable I/O for databases.
- The storage layer already offers snapshots and thin provisioning, such as LVM-thin, ZFS zvols or Ceph RBD. Adding qcow2 on top would duplicate features and add overhead.
Block storage instead of files
- LVM: each VM gets a logical volume. Fast and simple; LVM-thin adds thin provisioning and snapshots. See LVM basics.
- ZFS: zvols with checksums, compression and instant snapshots; needs plenty of RAM.
- Ceph RBD: distributed storage across nodes, enabling live migration without shared NFS.
Panels like Virtualizor and VirtFusion support several of these; see VirtFusion storage options and Virtualizor LVM-thin storage.
Useful qemu-img commands
Inspect an image:
qemu-img info /var/lib/libvirt/images/web01.qcow2Create a qcow2 disk with metadata preallocation:
qemu-img create -f qcow2 -o preallocation=metadata disk.qcow2 50GConvert raw to qcow2:
qemu-img convert -p -O qcow2 disk.raw disk.qcow2Grow a disk by 20 GB (then extend the partition and filesystem inside the guest):
qemu-img resize disk.qcow2 +20GTroubleshooting
- Host disk full though VMs look small: thin qcow2 images grew; monitor real usage with
du -h, not apparent size. - "Could not open... Permission denied": check ownership and AppArmor/SELinux labels on the image path.
- Slow qcow2 writes: use
cache=none,io=nativeand virtio-scsi or virtio-blk.
Frequently asked questions
Is raw always faster than qcow2?
Slightly, but on modern QEMU the difference is small for most workloads. The underlying disk (NVMe vs HDD) matters far more.
Can I shrink a qcow2 image?
Run fstrim in the guest with discard enabled, or rewrite the image with qemu-img convert to reclaim unused space.
What format do VPS providers use?
It varies: many use LVM or ZFS block devices with raw volumes, others qcow2 files on local NVMe.