Create & Attach Cinder Volumes in OpenStack

An instance's root disk lives and dies with the instance. The moment you need data to survive a rebuild, a resize, or a move to another hypervisor, you need block storage that exists independently of compute. In OpenStack that service is Cinder, and on a serious cloud it is usually backed by Ceph so every volume is replicated and resilient.

This tutorial covers the full lifecycle: create a volume, attach it to a running instance, format and mount it inside the guest, and snapshot it for backups. It picks up where launching your first instance left off, and it mirrors local storage concepts like LVM at the cloud layer.

Prerequisites

• A running OpenStack 2025.2 cloud with the openstack client and project-scoped credentials.
• A running instance (for example web-01) that you can SSH into.
• Enough volume and gigabyte quota in your project — check with openstack quota show.

Step 1: Create a volume

Create an empty 10 GB volume. If your cloud offers multiple volume types (for example SSD-backed versus capacity tiers), pass --type; otherwise the default type is used:

openstack volume create --size 10 --description 'app data' data-vol01
openstack volume list

A freshly created volume reports available status, meaning it exists but is not yet attached to anything:

openstack volume show data-vol01 -c status -c size
# | size   | 10        |
# | status | available |

Step 2: Attach the volume to an instance

Attach the volume to your instance. Nova hands it to the guest as a new block device, typically /dev/vdb (the next free virtio disk):

openstack server add volume web-01 data-vol01
openstack volume show data-vol01 -c status -c attachments
# status changes to 'in-use'

Step 3: Format and mount inside the guest

The volume is now visible inside the instance but is raw. SSH in, confirm the device, create a filesystem, and mount it:

ssh -i ~/.ssh/mykey.pem ubuntu@203.0.113.50
lsblk
sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /mnt/data
sudo mount /dev/vdb /mnt/data
df -h /mnt/data

Make the mount persistent

To survive reboots, add the volume to /etc/fstab using its UUID rather than the device name, which can change:

sudo blkid /dev/vdb
# copy the UUID, then:
echo 'UUID=<your-uuid> /mnt/data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab
sudo mount -a

Step 4: Snapshot the volume for backups

A snapshot captures the volume at a point in time and is the basis of backups and clones. For a crash-consistent snapshot you can use --force while the volume is attached, though quiescing the filesystem first is safer:

openstack volume snapshot create --volume data-vol01 data-vol01-snap-2026-05-27
openstack volume snapshot list

To recover, create a new volume from the snapshot and attach it like any other:

openstack volume create --snapshot data-vol01-snap-2026-05-27 --size 10 data-vol01-restored

Step 5: Grow a volume

Volumes can be extended online on most backends. Detach-free growth depends on your driver; the safe, universal path is to detach, extend, reattach, then grow the filesystem inside the guest:

openstack server remove volume web-01 data-vol01
openstack volume set --size 20 data-vol01
openstack server add volume web-01 data-vol01
# inside the guest:
sudo resize2fs /dev/vdb

Verification

Confirm the volume is attached, mounted, and persistent. After a reboot of the instance the data and mount should still be present:

openstack volume list
openstack server show web-01 -c volumes_attached
# inside the guest after reboot:
df -h /mnt/data && ls -la /mnt/data

Common errors and troubleshooting

Volume stuck in 'attaching' or 'detaching'

This usually points to a Nova/Cinder communication hiccup or a busy backend. Check openstack volume show for the state and the Cinder logs; an admin can reset a wedged state with cinder reset-state if it does not clear on its own.

Device not visible in the guest

Run lsblk again — the kernel may need a moment. If it never appears, confirm the attachment succeeded with openstack server show -c volumes_attached and that the guest has the virtio drivers (all modern cloud images do).

Cannot delete a volume

A volume that is in-use or has snapshots cannot be deleted. Detach it first, delete dependent snapshots, then delete the volume.

Quota exceeded

If creation fails on quota, you have hit the project's volume count or gigabyte limit. Review with openstack quota show and clean up or request more, as covered in project and quota setup.

Cleaning up

openstack server remove volume web-01 data-vol01
openstack volume snapshot delete data-vol01-snap-2026-05-27
openstack volume delete data-vol01

Conclusion

You have added persistent, snapshot-able block storage to a cloud instance and made it survive reboots, rebuilds, and resizes. Backed by a distributed store like Ceph, these volumes are replicated and resilient — the cloud equivalent of the flexible storage you build by hand with LVM, but self-service and API-driven. Pair this with tenant networking and a running instance for a complete, stateful workload.

Operating that Ceph backend — sizing OSDs, tuning replication, and guaranteeing durability — is exactly what clouditiv runs for you on a managed on-premise cloud, so your volumes are resilient by default and your data stays in Germany.