☁️ OpenStack Error: Cinder Quota Usage Out of Sync (Over Quota With No Volumes)

Exact Error Message

$ openstack volume create --size 10 data-vol
VolumeLimitExceeded: Maximum number of volumes allowed (10) exceeded for
quota 'volumes'. (HTTP 413) (Request-ID: req-2a7c1e93-8b4d-4f0a-9c2e-1d3f4a5b6c7d)

The tell-tale sign of a sync problem rather than a genuinely full project is that openstack volume list shows far fewer (or zero) volumes than the quota claims are in use:

$ openstack quota show --detail my-project -c volumes
+---------+--------------------------------------------+
| Field   | Value                                      |
+---------+--------------------------------------------+
| volumes | {'in_use': 10, 'limit': 10, 'reserved': 0} |
+---------+--------------------------------------------+

What It Means

Cinder tracks quota usage in the quota_usages table in its database, incrementing and decrementing counters as volumes, snapshots, and gigabytes are created and deleted. When those counters drift away from the real object count — because a delete failed to decrement, a reservation was orphaned, or a race left a stale row — the database believes the project is at its limit even though the actual volumes no longer exist. Cinder then rejects new requests with an over-quota error for resources that are not really consumed.

This is a bookkeeping drift, not a storage-backend failure. The volumes are gone; only the accounting is wrong.

Common Causes

• A volume or snapshot delete failed partway, decrementing nothing or leaving a deleting/error_deleting row.
• Orphaned quota reservations that were never committed or rolled back (often after an API restart mid-request).
• Directly manipulating the database or restoring an old DB dump that predates deletions.
• A Cinder bug or crash during a create/delete transaction that left quota_usages inconsistent.
• Nested quotas / quota-class changes applied while operations were in flight.

Diagnostic Commands

Compare claimed usage against the real object count for the project:

openstack quota show --detail my-project -c volumes -c snapshots -c gigabytes
openstack volume list --project my-project -f value -c ID | wc -l

Look for volumes stuck in a transient/error state that inflate usage:

openstack volume list --project my-project --long -c ID -c Status

Inspect the raw usage rows the scheduler trusts (on the Cinder DB host):

mysql cinder -e "SELECT resource, in_use, reserved FROM quota_usages \
  WHERE project_id='<PROJECT_UUID>';"

Check for stale reservations that were never expired:

mysql cinder -e "SELECT resource, delta, expire FROM reservations \
  WHERE project_id='<PROJECT_UUID>';"

Review the volume service logs for failed deletes around the drift:

sudo journalctl -u devstack@c-vol --no-pager | grep -i "quota\|error_deleting"
# package installs: /var/log/cinder/cinder-volume.log

Step-by-Step Resolution

1. Confirm this is drift, not a real limit: the object count from openstack volume list must be lower than the in_use value reported by quota show.

2. Clean up any volumes genuinely stuck in error_deleting, since those legitimately hold usage until removed:

openstack volume set --state error <VOLUME_ID>
openstack volume delete --force <VOLUME_ID>

3. Expire orphaned reservations. Cinder normally expires them automatically, but you can trigger the reconciliation with the management tool:

cinder-manage --debug quota sync --project-id <PROJECT_UUID>

4. If quota sync is unavailable on your release, refresh usage by recalculating from real objects (test in staging first). The cinder-manage quota sync path is preferred over hand-editing rows.

5. As a last resort, and only after backing up the database, correct the stale counter directly:

mysql cinder -e "UPDATE quota_usages SET in_use=0, reserved=0 \
  WHERE project_id='<PROJECT_UUID>' AND resource='volumes';"

6. Restart the Cinder API/scheduler so cached usage is reloaded, then re-test the create:

sudo systemctl restart devstack@c-api devstack@c-sch
openstack volume create --size 10 data-vol

7. Confirm quota show --detail now reports an in_use value that matches the real volume count.

Prevention

• Prefer cinder-manage quota sync for reconciliation instead of editing quota_usages by hand.
• Investigate and clear error_deleting volumes promptly so usage does not accumulate phantom counts.
• Avoid restoring stale Cinder DB dumps into a live environment without re-syncing quotas afterward.
• Keep Cinder services patched; several historical quota-drift races have been fixed upstream.
• Monitor for divergence by periodically comparing quota_usages.in_use against actual object counts and alerting on mismatches.

Related Errors

• QuotaError: Quota exceeded for resources: ['gigabytes'] — the same drift on capacity rather than count.
• VolumeIsBusy: Volume ... is still attached — a delete blocked because the volume is in use, which can precede drift.
• error_deleting volume status — a failed delete that inflates usage until cleaned up.
• Over quota on snapshots — the identical reconciliation applies to the snapshots resource.

Frequently Asked Questions

How do I know the quota is really out of sync and not just full? Compare the in_use count from openstack quota show --detail with the actual number of volumes from openstack volume list. If usage is higher than the real count, it is drift.

Is it safe to edit the quota_usages table directly? Only as a last resort, after a database backup, and after restarting the Cinder services. The supported path is cinder-manage quota sync, which recalculates usage from real objects.

Why did the drift happen in the first place? Usually a delete that failed to decrement the counter, an orphaned reservation left by a mid-request restart, or a DB restore that predates deletions.

Do I need to restart Cinder after fixing usage? Yes. The API and scheduler cache quota state, so restart c-api/c-sch (or cinder-api/cinder-scheduler) for the corrected counts to take effect. For quota-audit prompts, see the OpenStack prompts.

Can this happen for gigabytes as well as volume count? Yes — the same quota_usages mechanism tracks gigabytes and snapshots, and the same cinder-manage quota sync reconciles all of them. For more storage guides, see the OpenStack guides.