Using OpenStack Shelve/Unshelve to Temporarily Free Compute Resources

Problem: Idle instances waste compute capacity

In many clouds, development or test workloads run only part of the day. Leaving those instances on compute hosts ties up CPU and memory that could be used for other tenants, increasing operational cost without delivering value.

Thesis: Shelve/unshelve lets you offload an instance’s disk to shared storage while preserving its metadata, freeing the host and allowing a quick restore when needed.

How shelving works

When you run openstack server shelve, OpenStack:

1. Moves the instance’s root disk image from the compute host’s local storage to a shared backend (Ceph RBD, NFS, etc.).
2. Keeps the instance’s metadata (flavor, security groups, VIF bindings) in the Nova database.
3. Changes the instance status to SHELVED and removes the libvirt domain from the host, so virsh list no longer shows the VM.

The instance remains billable as a Nova object, but the compute node is free to schedule other workloads.

Worked example: shelve then unshelve a test instance

Assume you have an instance named test-web-01 with ID abcd1234-ef56-7890-abcd-ef1234567890 running on a compute host that uses Ceph for shared storage.

1. Shelve the instance

# Run on a controller or any node with openstack client auth
openstack server shelve abcd1234-ef56-7890-abcd-ef1234567890

Required permission: the user must have the compute:server:shelve policy (typically granted to admin or project member roles).

2. Verify the shelve

• Check Nova status:

openstack server show abcd1234-ef56-7890-abcd-ef1234567890 -f value -c status

Expected output: SHELVED.

• Confirm the compute host no longer runs the VM:

# Replace  with the actual compute host name
ssh  'sudo virsh list --name'

The instance’s libvirt domain should be absent.

• Check that the disk image resides on shared storage (Ceph example):

# List RBD images in the volumes pool
sudo rbd ls -p volumes | grep abcd1234-ef56-7890-abcd-ef1234567890

You should see an image named like volume-.

3. Unshelve when the workload is needed again

openstack server unshelve abcd1234-ef56-7890-abcd-ef1234567890

Required permission: compute:server:unshelve.

4. Verify the unshelve

• Status returns to ACTIVE:

openstack server show abcd1234-ef56-7890-abcd-ef1234567890 -f value -c status

• The VM reappears on a compute host (may be the same or a different one):

openstack hypervisor show  -f value -c hypervisor_hostname

Or check libvirt on the host:

ssh  'sudo virsh list --name | grep abcd1234-ef56-7890-abcd-ef1234567890'

• The disk image is no longer listed as a separate RBD image in the volumes pool (it has been attached back to the instance):

sudo rbd ls -p volumes | grep abcd1234-ef56-7890-abcd-ef1234567890 || echo "not found (expected)"

Trade‑offs and limitations

• Root disk must be on shared storage. If the instance uses local ephemeral storage for its root disk, shelving will not preserve that data; the disk is lost after unshelve.
• Unshelve depends on host resources. The target compute host must have sufficient free CPU, RAM, and the shared storage backend must be reachable and performant. High latency or temporary unavailability can cause the unshelve to fail, leaving the instance in SHELVED_OFFLOADED state.
• Network interfaces are re‑attached, but floating IPs are preserved automatically. However, any security group rules that rely on the instance’s host‑specific metadata (e.g., host aggregates) need to be re‑evaluated after unshelve.

Actionable closing

To start saving compute cycles today:

1. Identify instances that run only part of the day and whose root disk resides on shared storage (Ceph, NFS, etc.).
2. Create a simple cron job or Heat template that runs openstack server shelve <id> after business hours and openstack server unshelve <id> before the next work period.
3. Add the verification steps above to your automation so you can alert if shelve/unshelve fails.
4. Monitor the compute host’s free resources; you should see a measurable increase in available vCPU and RAM during the shelved window.

By treating shelve/unshelve as a routine lifecycle operation, you can align resource consumption with actual workload patterns without sacrificing instance state or requiring manual migrations.