How qcow2 Overlays Work in QEMU | Celesto AI Blog

Skip to content

Go back<br>How qcow2 Overlays Work in QEMU<br>Aniket Maurya<br>6 Jun, 2026

We are using qcow2 disk images for our sandbox VMs.

A common question is whether qcow2 uses Linux overlayfs.

The answer is:

No. qcow2 does not use overlayfs.

qcow2 has its own copy-on-write mechanism built into QEMU at the block-device layer.

1. overlayfs vs qcow2

overlayfs is a Linux filesystem feature.

It is commonly used by containers. It layers one filesystem on top of another filesystem.

For example:

lowerdir/ # base filesystem<br>upperdir/ # writable changes<br>merged/ # final combined view<br>This works at the file and directory level.

qcow2 is different.

qcow2 works at the virtual disk block level. That means QEMU tracks changes in chunks of the VM’s disk image, not individual files and folders inside the guest OS.

The guest operating system does not know it is using an overlay. It just sees a normal disk.

This means qcow2 overlays work for:

Linux guests

Windows guests

other operating systems

That is why qcow2 is a good fit for VM-based sandboxes.

2. The basic idea

With QEMU, we can create a base image and then create a writable overlay on top of it.

base.qcow2<br>sandbox-123.qcow2<br>The base image contains the operating system and preinstalled software.

The overlay image stores only the changes made by one sandbox instance.

The base image remains unchanged.

3. Read path

When the VM reads from disk, QEMU checks the overlay first.

if block exists in overlay:<br>read from overlay<br>else:<br>read from base image<br>So if the sandbox has modified a block, QEMU reads the modified version from the overlay.

If the sandbox has not modified that block, QEMU reads it from the base image.

4. Write path

When the VM writes to disk, QEMU writes into the overlay image.

write goes to sandbox-123.qcow2<br>base.qcow2 stays unchanged<br>The base image is not modified.

This is what makes cheap sandbox cloning possible.

Each sandbox can get its own writable disk image without copying the full base image.

5. Creating a base image

A base image is usually a prepared VM disk.

For example:

qemu-img create -f qcow2 base.qcow2 40G<br>Then you install the OS, packages, agents, drivers, and tools into this image.

After the base image is ready, treat it as a golden image.

Ideally, make it read-only from the host side:

chmod 444 base.qcow2<br>This helps prevent accidental writes to the base image.

6. Creating a sandbox overlay

For each sandbox, create a new qcow2 overlay backed by the base image.

qemu-img create \<br>-f qcow2 \<br>-F qcow2 \<br>-b base.qcow2 \<br>sandbox-123.qcow2<br>Meaning:

-f qcow2 # create the new image as qcow2<br>-F qcow2 # backing file format is qcow2<br>-b base.qcow2 # use base.qcow2 as the backing image<br>The overlay starts very small.

It grows only as the VM writes new data.

7. Booting the sandbox

Now boot the VM using the overlay, not the base image.

qemu-system-x86_64 \<br>-m 4096 \<br>-smp 4 \<br>-drive file=sandbox-123.qcow2,format=qcow2,if=virtio \<br>-enable-kvm<br>The guest OS sees a normal disk.

Internally, QEMU reads unchanged blocks from base.qcow2 and writes changed blocks to sandbox-123.qcow2.

8. Resetting a sandbox

To reset a sandbox back to the original state, delete the overlay and create a new one.

rm sandbox-123.qcow2

qemu-img create \<br>-f qcow2 \<br>-F qcow2 \<br>-b base.qcow2 \<br>sandbox-123.qcow2<br>This gives a clean machine again without rebuilding or copying the full base image.

This is the common pattern for local development sandboxes.

9. Inspecting the backing chain

You can inspect the image and its backing file using:

qemu-img info sandbox-123.qcow2<br>You should see something like:

image: sandbox-123.qcow2<br>file format: qcow2<br>backing file: base.qcow2<br>backing file format: qcow2<br>To see the full backing chain:

qemu-img info --backing-chain sandbox-123.qcow2<br>This is useful for debugging.

10. Why this is useful for sandboxes

This design gives us:

fast sandbox creation

cheap per-sandbox disk state

easy reset

immutable base images

support for Windows and Linux guests

no dependency on guest filesystem internals

no need for Linux overlayfs

This is especially important for VM-based sandboxes because the guest may be Windows.

overlayfs is a Linux filesystem feature. It is not the right abstraction for Windows guest disks.

qcow2 works below the guest filesystem, so it does not care what filesystem the guest uses.

11. Mental model

The clean mental model is:

overlayfs = file-level copy-on-write for Linux filesystems

qcow2 backing files = block-level copy-on-write for VM disks<br>Or even shorter:

overlayfs is for containers.<br>qcow2 overlays are for VMs.<br>That is not perfectly precise, but it is the right practical intuition.

12. Common gotchas

1. Do not boot directly from the base image

The base image should be treated as immutable.

Booting directly from it can mutate the golden state.

Use a per-sandbox overlay instead.

2. Be careful with relative backing paths

When you...