Clones: copy-on-write images from snapshots

Why this matters in production

Cloning is what makes provisioning a hundred VMs from one template instantaneous instead of a copy operation per VM. It also creates a dependency chain that, unmanaged, becomes a read-performance problem and a deletion obstacle.

The workflow

# 1. prepare and snapshot the golden image
rbd create --size 40G rbd-templates/ubuntu-2404
# ... install and configure ...
rbd snap create rbd-templates/ubuntu-2404@v1

# 2. protect it — clones depend on it and it must not be deleted
rbd snap protect rbd-templates/ubuntu-2404@v1

# 3. clone, instantly
rbd clone rbd-templates/ubuntu-2404@v1 rbd-vms/web-01
rbd clone rbd-templates/ubuntu-2404@v1 rbd-vms/web-02

Each clone is created in milliseconds and initially consumes nothing.

The read path

graph LR
    A[read from clone] --> B{object exists in clone?}
    B -->|yes| C[return it]
    B -->|no| D[read from parent snapshot]

Unwritten regions of a clone read through to the parent — an extra RADOS lookup per such read. On a lightly-modified clone that is most reads.

Writes always allocate in the clone, so a clone diverges from its parent progressively as it is used.

Inspecting the relationship

rbd info rbd-vms/web-01 | grep -A2 parent
# parent: rbd-templates/ubuntu-2404@v1
# overlap: 40 GiB

rbd children rbd-templates/ubuntu-2404@v1
# rbd-vms/web-01
# rbd-vms/web-02

rbd du rbd-vms/web-01

overlap is how much of the clone still reads through to the parent.

Flattening

rbd flatten rbd-vms/web-01

Copies all parent data into the clone, removing the dependency. Afterwards the clone is an independent image consuming its full allocated size.

Do not flatten when clones are short-lived — a CI runner’s disk that exists for twenty minutes should stay thin.

The deletion obstacle

rbd snap unprotect rbd-templates/ubuntu-2404@v1
# Error: snapshot is protected and has children

A protected snapshot with children cannot be unprotected or removed. To retire a template you must flatten or delete every clone first — which is why rbd children should be checked before any template lifecycle decision.

Quiz

Production discipline

Record which template and version each provisioned volume came from, and flatten clones once they exceed a defined age — template retirement is otherwise an open-ended hunt. Keep object-map enabled on clones specifically, since the read-through path is where its absence costs most.

Cross-course references

• Kubernetes: PVC provisioning from a VolumeSnapshot uses the same mechanism
• Linux: overlayfs lower and upper layers behave identically, including the lookup cost