Cinder QoS Specs: Putting a Ceiling on OpenStack Storage Noisy Neighbors

The backup job that ate the storage array

You know the scene. A tenant kicks off a nightly backup or a careless fio benchmark on a volume that shares a backend with twenty other instances. Within minutes, latency climbs for unrelated VMs, and your monitoring dashboard turns red. The root cause is not a bug; it is the absence of a performance contract. In OpenStack, that contract is built from two pieces: Cinder Volume Types and Quality of Service (QoS) specs.

The useful takeaway is simple: a Volume Type tells Cinder where to place a volume, while a QoS spec attached to that type tells the platform how fast the volume is allowed to go. If you do not set the second limit, you are relying on hope and backend capacity.

Volume Types are a catalog, not a speed limit

Operators often create Volume Types such as ssd, hdd, or gold and assume the name alone enforces performance. It does not. A Volume Type is a scheduling hint and a metadata bucket. It can carry extra specs that a particular storage driver reads—for example, a provisioning type or a backend pool name—but the type itself does not throttle I/O. It answers the question "which backend should host this volume?"

To answer "how much I/O may this volume consume?" you need a QoS spec.

Front-end vs. back-end: where the limit actually bites

A Cinder QoS spec is a named set of properties—typically IOPS or throughput ceilings—that you associate with one or more Volume Types. The critical decision is the consumer field, which controls where the limit is enforced.

Enforcement point	What it does	What it protects	Key caveat
front-end	Nova/Libvirt applies a block I/O throttle to the VM's virtual disk.	The compute host and other VMs on the same hypervisor.	The storage array may still be flooded by volumes on other hosts.
back-end	The storage driver pushes the limit to the physical array or appliance.	The shared storage backend and all connected compute nodes.	Support varies by driver; unsupported arrays may ignore the limit silently.
both	Attempts enforcement at both layers.	Defense in depth.	Still depends on back-end driver capability.

If your goal is to stop a single VM from saturating a hypervisor's I/O path, front-end is reliable because it does not depend on the storage vendor. If your goal is to protect a shared SAN or NAS appliance from aggregate overload, you need back-end support, and you must verify that your Cinder driver actually implements it.

Worked example: capping a database volume at 2,000 read IOPS

Suppose your team runs a mixed-tenant OpenStack cloud backed by a shared iSCSI array. You want database volumes to be fast but predictable, so you decide to cap them at 2,000 read IOPS and 1,000 write IOPS. Run the following commands from a control node or admin workstation that has the OpenStack CLI installed and credentials for a cloud administrator or a user with the appropriate role-based access control (RBAC) permissions for volume types.

# 1. Create the volume type that will carry the policy
openstack volume type create db-capped-ssd

# 2. Define the QoS spec with front-end enforcement
openstack volume qos create db-iops-cap \
  --consumer front-end \
  --property read_iops_sec=2000 \
  --property write_iops_sec=1000

# 3. Bind the spec to the type
openstack volume qos associate db-iops-cap db-capped-ssd

# 4. Verify the association before creating volumes
openstack volume type show db-capped-ssd

In step 4, confirm that the output includes a qos_id field matching the ID returned when you created the QoS spec. If the field is missing, the association failed and new volumes will not inherit the limit.

Now create a volume with that type:

openstack volume create --type db-capped-ssd --size 100 db-data-01

Attach the volume to a VM, format it, and run a synthetic read workload. A simple check inside the guest is:

fio --name=readtest --rw=read --bs=4k --numjobs=1 --size=1G --direct=1

You should observe the reported IOPS plateau near the configured ceiling. Remember that fio measures what the guest sees; if you chose back-end enforcement on an unsupported driver, the guest may see no cap at all.

Changing the rules after volumes exist

If you need to adjust the QoS spec after volumes are already attached, be careful. Depending on your OpenStack release and the active storage driver, Cinder may require a detach/reattach cycle before the new limit takes effect on an existing volume. Plan for a maintenance window, or create a new Volume Type with the revised spec and migrate data.

The trade-off: QoS is not infinite capacity

The most common mistake is treating QoS specs as a substitute for capacity planning. A front-end cap protects the hypervisor, but it does not create extra IOPS on a saturated array. If twenty capped volumes all hit their limits simultaneously, the backend may still become the bottleneck, and latency will rise for everyone. Use QoS to enforce fairness, not to overbook physical hardware.

Back-end support is the other limitation. Before you rely on back-end enforcement, check your storage driver's documentation for the specific property names it honors. Property names and CLI syntax can shift between OpenStack releases, so verify against the documentation for your deployed version rather than assuming a previous cloud's configuration will port cleanly.

What to do next

• Audit existing Volume Types: do any lack a QoS spec on a shared backend?
• Start with front-end caps for compute-host protection; coordinate with your storage team before enabling back-end limits.
• After associating a spec, run openstack volume qos show and openstack volume type show to confirm the link, then validate with a short fio run inside a test VM.

Storage performance does not have to be a lottery. Volume Types give you placement; QoS specs give you boundaries. Set both, verify where the limit is enforced, and benchmark before you promise tenants a number.