The snapshot and clone lifecycle end to end

Advanced⏱ ~18 minrbd

What you'll learn

Design a complete template-to-VM workflow
Automate provisioning from templates
Track lineage and manage versions
Handle the operational edge cases

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

The individual commands are simple. The workflow that stays maintainable after two years and ten thousand provisioned volumes is not, and the difference is entirely in the operational practices layered around the same handful of commands.

The workflow

# --- template build ---
rbd create --size 40G rbd-templates/ubuntu-2404-base
# install, configure, generalise (remove machine-id, ssh host keys, etc.)
rbd snap create  rbd-templates/ubuntu-2404-base@v3
rbd snap protect rbd-templates/ubuntu-2404-base@v3

# --- provisioning ---
rbd clone rbd-templates/ubuntu-2404-base@v3 rbd-vms/web-07
rbd image-meta set rbd-vms/web-07 template ubuntu-2404-base@v3
rbd image-meta set rbd-vms/web-07 provisioned "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
rbd resize --size 100G rbd-vms/web-07

# --- maintenance ---
rbd flatten rbd-vms/web-07        # once it exceeds the flatten age

# --- decommission ---
rbd rm rbd-vms/web-07

The image-meta lines are what make the whole thing tractable later: lineage travels with the image rather than living in a database that drifts.

Templates across pools

A clone must be in the same pool as its parent unless the cluster supports cross-pool cloning. Where it does not, either keep templates in each pool or copy the template into the target pool:

rbd cp rbd-templates/ubuntu-2404-base@v3 rbd-vms/ubuntu-2404-base
rbd snap create  rbd-vms/ubuntu-2404-base@v3
rbd snap protect rbd-vms/ubuntu-2404-base@v3

Reporting on the estate

# what came from which template
for i in $(rbd ls rbd-vms); do
  printf '%-24s %s\n' "$i" "$(rbd image-meta get rbd-vms/$i template 2>/dev/null || echo '-')"
done

# outstanding dependencies per template version
for s in $(rbd snap ls rbd-templates/ubuntu-2404-base --format json | jq -r '.[].name'); do
  printf '%-8s %s children\n' "$s" "$(rbd children rbd-templates/ubuntu-2404-base@$s | wc -l)"
done

These two reports answer the questions that actually come up: what is this VM based on, and can this template version be retired.

Edge cases

Situation	Handling
Clone larger than the template	`rbd resize` after cloning; the extra space is unallocated
Template needs a fix	new snapshot version, do not modify the existing one
Clone of a clone	supported, but adds a read-through level — flatten instead
Template pool full	flatten old clones or move the template
Orphaned clone after a failed provision	detect via images with no matching VM record

Cloning a clone is the one to avoid: each level adds another read-through lookup on unwritten regions, and a chain several deep is measurably slower for no benefit over flattening at the first level.

Quiz

Knowledge check · 4 questions

Q1. Why should you avoid creating clones of clones?

Each level adds a read-through lookup on unwritten regions, degrading cold-read latency Ceph does not support cloning an image that is itself already a clone It doubles capacity consumption, because every level allocates a full copy of the parent's objects The intermediate clone becomes read-only once something is cloned from it
Q2. Writing to a template image after clones exist changes what those clones read.

True False
Q3. Make a template estate maintainable.

A platform has provisioned 3,000 VMs from templates over three years. Nobody can determine which VM came from which template version, several template versions have unknown numbers of dependants, and the templates pool is approaching capacity.
Q4. What operational purpose does recording template lineage in image metadata serve?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Record lineage in image metadata at provisioning time; the cost is one command and it converts template retirement from an investigation into a query. Flatten at the first clone level rather than allowing chains, and cap live template versions so the dependency graph stays shallow and countable.

Cross-course references

Kubernetes: container image tags and their provenance tracking face the identical problem
Linux: golden-image workflows with a build pipeline follow this same versioning discipline