Should Low‑Traffic Workloads Use Boot‑From‑Image or Boot‑From‑Volume in OpenStack?

Question

For a low‑traffic workload the operator wants to minimize monthly expenses while retaining the ability to snapshot and recover instances. The decision hinges on whether to boot instances from the local ephemeral disk (boot‑from‑image) or from a Cinder volume (boot‑from‑volume). Boot‑from‑image avoids per‑GB volume charges and network attachment overhead, but it consumes compute‑node storage that is not limited by Nova’s ram_allocation_ratio or cpu_allocation_ratio, requiring separate monitoring of host disk usage to prevent out‑of‑space failures.

Boot‑from‑volume shifts the cost to Cinder storage and introduces additional network traffic, yet provides easy snapshotting and volume‑based mobility. Using a lower‑performance Cinder backend or disabling volume backups can cut expenses, but the effect on durability and restore time for infrequently accessed data is unclear.

How does ephemeral‑disk consumption influence Nova scheduler placement when ram_allocation_ratio and cpu_allocation_ratio are adjusted?
What level of cost saving is achievable by disabling Cinder backups or switching to a reduced‑replication backend for boot‑from‑volume instances?
Can the reduced durability of a low‑cost Cinder backend be tolerated for workloads that experience only occasional read/write traffic?

Tasadduq Burney · Answer

Answer to the Core Question
For a low‑traffic, cost‑sensitive workload that does not need to preserve local state across reboots, boot‑from‑image is the recommended approach. It eliminates per‑GB volume charges, reduces launch latency, and keeps compute‑node storage usage predictable. If the workload must retain data or be snapshotted quickly, boot‑from‑volume becomes preferable.
Why Boot‑From‑Image Usually Wins

Zero per‑instance storage cost – no Cinder volume is created.
Lower launch latency – the image is read‑only and served directly from Glance.
Simpler scaling – the same image can be used to spin up many instances without additional storage provisioning.
Reduced scheduler complexity – placement decisions rely only on CPU/ram ratios, not disk quotas.

When Boot‑From‑Volume Should Be Considered

Workload writes data that must survive instance termination or migration.
Rapid snapshotting and cloning of the root filesystem is required.
The underlying image backend is a shared filesystem that would otherwise duplicate data on every launch.

Practical Steps for Boot‑From‑Image

Create a base image in Glance:
openstack image create "my-base" \
  --file /path/to/image.qcow2 \
  --disk-format qcow2 \
  --container-format bare \
  --public

Launch an instance using that image:
openstack server create "my-instance" \
  --image my-base \
  --flavor m1.tiny \
  --network private

Verify that no Cinder volume is attached:
openstack server show my-instance | grep "volume_id"

Optional: snapshot the instance by creating a new image from the running VM (this requires a full image copy, not a volume snapshot).

Practical Steps for Boot‑From‑Volume (if needed)

Create a Cinder volume:
openstack volume create --size 10 boot-vol

Launch an instance with that volume as root:
openstack server create "my-volume-instance" \
  --image my-base \
  --flavor m1.tiny \
  --volume boot-vol \
  --network private

Snapshot the root volume for quick recovery:
openstack volume snapshot create --name snap-1 boot-vol

Key Diagnostic Detail
If your workload must retain local writes across reboots or requires frequent, lightweight snapshots, boot‑from‑volume would be the safer choice. Otherwise, boot‑from‑image remains the most cost‑effective option.

Should Low‑Traffic Workloads Use Boot‑From‑Image or Boot‑From‑Volume in OpenStack?

1 answer

Answer to the Core Question

Why Boot‑From‑Image Usually Wins

When Boot‑From‑Volume Should Be Considered

Practical Steps for Boot‑From‑Image

Practical Steps for Boot‑From‑Volume (if needed)

Key Diagnostic Detail

Your perspective belongs here.

1 question comment