Skip to main content

​
Overview

The image cache stores a local copy of frequently-used images on each compute node, eliminating repeated downloads from the central image service at instance launch time. Enabling the cache is most impactful when the same image is used to launch many instances on the same compute node — typical in auto-scaling and cluster workloads.
Administrator Access Required — This operation requires the admin role. Contact your Xloud administrator if you do not have sufficient permissions.

​
Cache Configuration

Configure cache settings via XDeploy globals before deploying:
SettingDefaultDescription
glance_enable_image_cachenoEnable the image cache
glance_cache_max_size10 GBMaximum total size of the cache directory
glance_cache_staleness_seconds86400How long a cached entry remains fresh (seconds)
glance_cache_prefetcher_delay300Seconds between pre-fetch sweep runs
Image cache configuration in XDeploy globals
glance_enable_image_cache: "yes"
glance_cache_max_size: 10737418240      # 10 GB in bytes
glance_cache_staleness_seconds: 86400   # 24 hours
glance_cache_prefetcher_delay: 300      # 5 minutes
Deploy after configuring:
Apply image cache configuration
xavs-ansible deploy --tags glance

​
How the Cache Works

​
Verify Cache Status

Check cache directory on Image API node
docker exec glance_api ls -lh /var/lib/glance/image-cache/
View cached image entries
docker exec glance_api glance-cache-manage list-cached
View pending pre-fetch queue
docker exec glance_api glance-cache-manage list-queued

​
Manual Cache Management

Queue an image for pre-caching before its first use:
Queue image for pre-fetch
docker exec glance_api glance-cache-manage queue-image <IMAGE_ID>
The pre-fetcher picks it up on the next sweep interval.

​
When to Use the Cache

Best case: Many instances from same image

The cache provides the greatest benefit when the same image is repeatedly used on the same compute node — typical patterns include:
  • Auto-scaling groups launching many identical instances
  • Development clusters where all developers use the same base image
  • CI/CD pipelines that launch many ephemeral test instances
After the first launch (cache miss), all subsequent launches are served from the local cache — typically 10-50x faster than fetching from the storage backend.
When both the Image Service and Block Storage use Xloud Distributed Storage (RBD), instance launches use zero-copy RBD clones. This already achieves near-instantaneous boot times regardless of image size — the image cache provides minimal additional benefit in this configuration.
Enable the image cache on compute nodes with SSD-backed local storage. Storing the cache on slow HDDs may actually increase launch latency compared to fetching from a fast Ceph cluster.

​
Next Steps

Storage Backends

Configure the primary storage backend that feeds the cache.

Architecture

Understand where the cache fits in the overall Image Service topology.

Admin Troubleshooting

Diagnose cache effectiveness and storage issues.

Quotas

Control storage consumption to ensure cache space is not exhausted.