Glance Cinder-Store & Image-Volume Cache Tuning Prompt
Tune the Glance cinder store and Cinder's image-volume cache so booting from image skips redundant downloads and uses backend-side cloning.
- Target user
- Advanced Glance/Cinder operators on Ceph or SAN backends
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior operator who tunes the Glance/Cinder image pipeline for fast boot-from-volume. I will provide: - OpenStack release, Glance stores config (`enabled_backends`, cinder store stanza) and Cinder backend type (Ceph RBD, SAN, LVM) - Cinder image-volume cache config (`image_volume_cache_enabled`, max size/count) and the volume-type used for the cache - Whether Glance and Cinder share the same Ceph pool (RBD clone path) and the `glance_api_version`/`rbd` settings - The symptom: slow boot-from-image, full copies instead of clones, cache thrash, or "image not cached" every time - Timing data or logs showing where the boot path spends time Your job: 1. **Clone-path analysis** — determine whether your stack qualifies for the fast RBD/backend clone path or is falling back to download-and-copy, and why. 2. **Cache effectiveness** — assess whether the image-volume cache is actually being hit (size/count limits, eviction, wrong volume-type) vs silently bypassed. 3. **Store alignment** — verify Glance cinder-store and Cinder backend point at the same pool/backend so cloning is possible. 4. **Tuning plan** — config deltas to enable the clone path and right-size the cache, with the expected effect on boot time and backend IO. 5. **Capacity impact** — how the cache and clones consume backend space, and the eviction behavior to expect. 6. **Validation** — how to prove the clone path is taken (RBD `children`/`info`, Cinder logs) after the change. Output as: (a) a current-vs-target boot-path diagram, (b) a cache + store config delta, (c) a validation plan proving clones replace copies. Validate the clone path and cache hit on one volume-type before enabling broadly; watch backend capacity as clones and cache volumes accumulate.
Why this prompt works
Boot-from-volume performance lives or dies on one question: is Cinder cloning the image inside the backend, or is it downloading the image through Glance and copying it byte-by-byte? The two paths can differ by orders of magnitude, and the config that selects between them is subtle — Glance’s cinder store and Cinder’s backend must point at the same pool, the image-volume cache must be enabled with the right volume-type, and on Ceph the RBD clone path has its own prerequisites. This prompt forces the model to determine which path your stack actually takes before recommending anything, because tuning the cache is pointless if you never qualify for clones.
The cache-effectiveness step addresses the most common silent failure: the image-volume cache is enabled but never hit because its size/count limits are too small or the wrong volume-type is configured, so every boot pays the full-copy cost while operators assume caching is working. Making the model verify hits via RBD children and Cinder logs turns “we enabled the cache” into “we proved the cache is used.”
The capacity guardrail matters because both clones and cached images consume real backend space, and an over-eager cache can fill a pool. By requiring a current-vs-target boot-path diagram and a single-volume-type validation before broad rollout, the prompt keeps a performance optimization from turning into a capacity incident — the human verifies the speedup and watches the pool while the AI handles the analysis.