🚨 OpenStack Error Guide: 'Volume stuck in creating' and 'failed to attach volume' in Cinder

Overview

A Cinder volume that never leaves creating, drops into error, or refuses to attach is one of the most common block-storage failures in OpenStack. The user-facing message is usually one of these:

Build of instance aborted: Volume <id> did not finish being created even after we waited 0 seconds or 0 attempts. And its status is error.

or, on attach:

VolumeAttachmentNotFound: Volume attachment <id> could not be found.
Failed to attach volume <id> at /dev/vdb - libvirtError: internal error: unable to execute QEMU command 'device_add': Property 'scsi-block.drive' can't find value 'drive-...'

This occurs when the cinder-volume service cannot reach its storage backend, when the scheduler cannot place the request, when a quota is exhausted, when the driver configuration is wrong, or when the iSCSI/multipath path between the compute host and the backend is broken. The volume itself is often fine — the failure is in the control or data path around it.

Symptoms

• A volume sits in creating for minutes, then flips to error.
• openstack volume create returns success but the volume never becomes available.
• An instance boot from volume hangs, then aborts with “Volume did not finish being created.”
• openstack server add volume reports the volume attaches in Cinder but the guest never sees /dev/vdb.

openstack volume list --all-projects

+--------------------------------------+----------+----------+------+-------------+
| ID                                   | Name     | Status   | Size | Attached to |
+--------------------------------------+----------+----------+------+-------------+
| 4a7d2c91-1f33-4d0e-9b21-8c6e0a1f7b22 | data-01  | error    |   50 |             |
| 9c1e44a0-77b2-4e5d-bb10-2f9a3c6d8e41 | data-02  | creating |  100 |             |
+--------------------------------------+----------+----------+------+-------------+

openstack volume show 4a7d2c91-1f33-4d0e-9b21-8c6e0a1f7b22 -c status -c "os-vol-host-attr:host"

+----------------------+-----------------------------------+
| Field                | Value                             |
+----------------------+-----------------------------------+
| status               | error                             |
| os-vol-host-attr:host| None                              |
+----------------------+-----------------------------------+

A host of None means the scheduler never assigned the volume to a backend — the failure is upstream of the driver.

Common Root Causes

1. cinder-volume service is down or backend reports down

If the cinder-volume service is down, the scheduler has nowhere to place new volumes.

openstack volume service list

+------------------+------------------------+------+---------+-------+----------------------------+
| Binary           | Host                   | Zone | Status  | State | Updated At                 |
+------------------+------------------------+------+---------+-------+----------------------------+
| cinder-scheduler | controller01           | nova | enabled | up    | 2026-06-23T14:02:11.000000 |
| cinder-volume    | controller01@lvm       | nova | enabled | down  | 2026-06-23T13:41:55.000000 |
+------------------+------------------------+------+---------+-------+----------------------------+

A State of down with a stale Updated At is the smoking gun. Check the service is actually running:

# Kolla-Ansible deployments
docker ps --filter name=cinder_volume --format '{{.Names}}\t{{.Status}}'
# Traditional / packaged deployments
systemctl status openstack-cinder-volume

2. Storage backend connectivity (LVM / Ceph / NetApp)

Even when the service is up, the driver may not reach the backend.

# LVM backend - is the volume group present and has free space?
vgs cinder-volumes
# Ceph (RBD) backend - can the host reach the cluster?
ceph -s --id cinder
rbd -p volumes ls --id cinder | head

2026-06-23 14:05:33.221 7 ERROR cinder.volume.drivers.rbd [req-...] error connecting to ceph cluster
rados.Rados: [errno 110] RADOS timed out (error connecting to the cluster)

For NetApp/iSCSI backends, confirm the management LIF answers:

curl -k -s -o /dev/null -w "%{http_code}\n" https://<netapp-mgmt-ip>/servlets/netapp.servlets.admin.XMLrequest_filer

3. Quota exhausted

The request can fail simply because the project is out of volume or gigabyte quota.

openstack quota show <project-id> -c volumes -c gigabytes
openstack volume list --project <project-id> --all-projects -c ID -c Size

QuotaError: VolumeLimitExceeded: Maximum number of volumes allowed (10) exceeded for quota 'volumes'.

4. Driver / configuration errors

A typo in cinder.conf or a missing backend section stops volumes before they start.

# Kolla-Ansible
docker exec cinder_volume grep -A15 '\[lvm\]' /etc/cinder/cinder.conf
# Traditional
grep -A15 '\[lvm\]' /etc/cinder/cinder.conf

2026-06-23 14:07:02.118 7 ERROR cinder.volume.manager Bad or unexpected response from the storage volume backend API: volume group cinder-volumes-fast not found

The volume_group in config does not match the actual VG name.

5. Scheduler: “Filtering removed all hosts”

When no backend satisfies the request (capacity, capabilities, volume type extra-specs), the scheduler rejects it.

# Kolla-Ansible
docker logs cinder_scheduler 2>&1 | grep -i "removed all hosts" | tail
# Traditional
journalctl -u openstack-cinder-scheduler | grep -i "removed all hosts" | tail

2026-06-23 14:08:44.902 7 WARNING cinder.scheduler.filter_scheduler [req-...] No weighed backends found for volume with properties: {'volume_type': 'ceph-ssd'}
2026-06-23 14:08:44.903 7 ERROR cinder.scheduler.manager Failed to schedule_create_volume: No valid backend was found. No weighed backends available

This is almost always a volume-type extra_specs (volume_backend_name) that no live backend advertises, or a backend reporting full.

6. iSCSI / multipath path broken on the compute host

Creation can succeed but attach fails when the data path between compute and backend is down.

# On the compute node
iscsiadm -m session
multipath -ll

iscsiadm: No active sessions.
2026-06-23 14:11:20.553 7 ERROR os_brick.initiator.connectors.iscsi Could not login to any iSCSI portal. Failed to find a target portal.

Bonus: oslo.messaging / RabbitMQ failures

The scheduler, volume, and API services talk over RPC. A broken message bus makes volumes hang in creating with no error at all.

openstack volume service list   # all hosts show 'down' despite running
docker logs cinder_volume 2>&1 | grep -i "AMQP\|MessagingTimeout" | tail

ERROR oslo.messaging._drivers.impl_rabbit [req-...] Connection failed: [Errno 111] ECONNREFUSED
MessagingTimeout: Timed out waiting for a reply to message ID ...

Diagnostic Workflow

Step 1: Confirm the volume’s real status and assigned host

openstack volume show <volume-id> -c status -c "os-vol-host-attr:host"

host = None points at the scheduler; a populated host points at that backend’s cinder-volume.

Step 2: Verify all Cinder services are up

openstack volume service list

Any down state with a stale timestamp means start there.

Step 3: Read the relevant service logs

# Kolla-Ansible
docker logs cinder_scheduler 2>&1 | tail -n 60
docker logs cinder_volume 2>&1 | tail -n 60
# Traditional
journalctl -u openstack-cinder-scheduler -n 60 --no-pager
journalctl -u openstack-cinder-volume -n 60 --no-pager

Match the req-... request ID from the API across scheduler and volume logs to follow one request end to end.

Step 4: Probe the backend directly from the volume host

vgs cinder-volumes                 # LVM
ceph -s --id cinder                # Ceph
iscsiadm -m session                # iSCSI/NetApp data path

Step 5: Check quota and message bus

openstack quota show <project-id> -c volumes -c gigabytes
rabbitmqctl list_queues name messages | sort -k2 -n -r | head

Example Root Cause Analysis

A user reports new volumes flip to error within seconds. The scenario:

1. openstack volume show reports status: error and os-vol-host-attr:host: None — the scheduler never placed it.

2. The scheduler log shows the cause:

2026-06-23 14:08:44.903 ERROR cinder.scheduler.manager Failed to schedule_create_volume:
No valid backend was found. No weighed backends available to handle the request.

3. Investigation — openstack volume service list shows cinder-volume on controller01@ceph-ssd in down state, last updated 40 minutes ago. On that host, ceph -s --id cinder times out with RADOS timed out. The Ceph mon network interface had flapped, and the cinder-volume container lost its connection.

4. Fix — restore the mon connectivity, then restart the driver so it re-establishes the RADOS session and re-reports capacity:

docker restart cinder_volume
# Traditional: systemctl restart openstack-cinder-volume
openstack volume service list   # confirm State returns to 'up'

New volumes now schedule and reach available. The original error volume is reset and retried:

openstack volume set --state available <volume-id>   # admin-only reset

Prevention Best Practices

• Alert on cinder-volume State: down by polling openstack volume service list and firing if any backend’s Updated At is older than 90 seconds.
• Monitor backend capacity directly — vgs free extents for LVM, ceph df pool usage for RBD — and alert before pools cross 80%.
• Watch RabbitMQ queue depth; a growing cinder-volume queue precedes hung creating volumes.
• Track per-project volume and gigabyte quota usage so capacity exhaustion is caught before it produces error volumes.
• Wire these signals into a runbook or an automated triage workflow such as the one at /dashboard/incident-response/ so the first responder gets the scheduler and backend logs without manual digging.

# Capacity and health snapshot for a quick health dashboard
openstack volume service list -f value -c Binary -c Host -c State
ceph df --id cinder
vgs --noheadings -o vg_name,vg_free cinder-volumes

Quick Command Reference

# Status and placement
openstack volume list --all-projects
openstack volume show <volume-id> -c status -c "os-vol-host-attr:host"
openstack volume service list

# Logs (Kolla-Ansible)
docker logs cinder_scheduler 2>&1 | tail -n 60
docker logs cinder_volume    2>&1 | tail -n 60
# Logs (traditional)
journalctl -u openstack-cinder-scheduler -n 60 --no-pager
journalctl -u openstack-cinder-volume    -n 60 --no-pager

# Backend probes
vgs cinder-volumes
ceph -s --id cinder
iscsiadm -m session
multipath -ll

# Quota and message bus
openstack quota show <project-id> -c volumes -c gigabytes
rabbitmqctl list_queues name messages | sort -k2 -n -r | head

# Admin recovery
openstack volume set --state available <volume-id>
docker restart cinder_volume   # or systemctl restart openstack-cinder-volume

Conclusion

When a Cinder volume is stuck in creating, lands in error, or fails to attach, the typical root causes are:

1. The cinder-volume service is down or reporting down to the scheduler.
2. The storage backend (LVM, Ceph, NetApp) is unreachable from the volume host.
3. Project volume or gigabyte quota is exhausted.
4. A driver or cinder.conf misconfiguration (wrong volume group or backend name).
5. The scheduler filtered out every host — usually a volume-type extra_specs mismatch or a full backend.
6. A broken iSCSI/multipath data path, or a failed oslo.messaging/RabbitMQ bus.

Walk the request from status, to services, to logs, to the backend in that order. More Cinder and block-storage troubleshooting lives under /categories/openstack/.