OpenStack Cinder QoS

OpenStack Cinder QoS

About this lab

The purpose of this lab is to show how to use QoS policies within OpenStack Cinder. We’ll be using Horizon (the GUI) for this lab, but the same could also be achieved using the CLI.

vTeam Specialization Program

Pure Storage nominated me recently to join the Pure Storage vTeam Specialization program for New Stack. The idea behind the program is, to create an active community within Pure Storage. Allowing Puritans to learn and develop their skills and grow into a subject matter experts.

The program consists of training and lab exercises that are focussed on developing experience in the New Stack space (Kubernetes, Ansible, Open Stack and more).

Since I think there are more people out there how want to learn more about New Stack, I will blog my progress in a series of lab exercises.

Lab instructions

The purpose of this lab is to use variables and facts from Ansible for building a more dynamic playbook.

Name:Cinder QoS
Description:Create volumes using QoS setting in OpenStack
Objective:Create different volumes with different QoS settings
Task #1:Define multiple QoS definitions in Cinder
Task #2:Create volume types for the QoS settings
Task #3:Associate QoS to volume types
Task #4:Create volumes with different QoS settings
Success Criteria:Volumes can be created with different QoS settings
Lab goals and tasks

This lab will be done in a single blog, since it doesn’t require too many steps. As said, I’ll be using the DevStack cluster that I’ve setup in the previous lab.

Creating Cinder QoS policy

The way QoS works in OpenStack Cinder is that you define a QoS policy, with read and write limits. You associate that QoS policy with a Volume Type (more on Volume Types here) and now that QoS policy applies to all volumes create with that Volume Type.

Create our QoS policy

Login to OpenStack Horizon and navigate to Admin -> Volume -> Volume Type.

Click on Create QoS types, as shown above. The following pop-up will appear. Provide a name for the policy, for example Gold, Silver and Bronze. I used 1000-iops, as I’ll specify both a read and write limit of 1000 IOPS.

Click Create.

Now that our policy is created, we need to define our limits. As the pop-up above already states, we need to edit the specs, so let’s hit the Manage Specs button.

I add two Key Value pairs:

  • read_iops_sec: 1000
  • write_iops_sec: 1000

However as the pop-up shows in the example, we could also use total_iops_sec if we do not want to differentiate between reads and writes, or use the total_bytes_sec_max to limit the bandwidth a consumer has available.

Once created, the Extra Specs will be listed for the QoS policy as shown below:

Associate our QoS policy to a Volume Type

Now that we’ve created our QoS policy, the next step is to associate it with a Volume Type. You could either use an existing Volume Type, or create a new one, which is what I’ll show below.

Click the Create Volume Type button. And enter a name in the following pop-up.

Click Create Volume Type to create the new Volume Type.

Next we can go into the dropdown menu for the (new) Volume Type, as shown below, and select Manage QoS Spec Association.

This allows us to select out QoS policy for this Volume Type. I’ll select the policy we just created.

Click on Associated.

Create a volume with Cinder QoS for OpenStack

The new Volume Type can be used to create volumes with the QoS policy applied. Doing so is simple.

When creating a new volume, make sure you select the Volume Type that has the correct QoS policy associated with it and that’s it.

Of course for a real life situation, we’d now probably go ahead and limit access for our consumer to only those Volume Types that we want them to use, so that they might only be able to choose the Gold, Silver, Bronze classes and the correct QoS will automatically be applied.


That concludes our lab to create Cinder QoS policies in OpenStack Cinder. We’ve seen how to create our policies and associate them to our Volume Types, after which they are available to our consumers. It should be noted here that OpenStack Cinder QoS policies are applied by the Hypervisor, so the underlying storage solution used has nothing to do with this.

I hope you’ve enjoyed the read, leave a comment if you did and I hope to see you soon in another blog.

Leave a Reply

Your email address will not be published.