OpenStack Cloud Storage Services: First Look at Folsom’s Cinder project

Sergey Kashaba - August 29, 2012 -


After the April Essex release, there’s big change in planned for OpenStack‘s volume management; it is now called Cinder.

Cinder is a new service for OpenStack, one that separates storage management logic. Until now, in the Essex release, this logic was a part of Nova, and was called the nova-volume component. But, as often happen in software, logical interdependencies between components within Nova became more and more complex, so the project developers decided to make storage management logic separate from Nova and create Cinder.

In fact, this is one of the first instances  of OpenStack’s recent development policy of breaking all Nova components into smaller building blocks. Nova had become a bulky piece of software;  development in one area was too often contingent on knowledge of others. By decoupling Nova into smaller chunks and interfacing them, developers can focus on developing these chunks as long as they provide the proper API for other services to plug in. This allows a better focus on different areas of OpenStack.

OpenStack Cinder: feature list

For Cinder, the separation from Nova is mainly organizational in nature—the project is now literally a copy-paste version of old nova-volume code with a separate database. The main goal for Cinder in the Folsom release is to provide the same API and features as in the current nova-volume, plus prepare for further focused work on the topic  in future releases.

The bottom line is: in Folsom we are just getting our old buddy nova-volume; at the same time, the developers managed to put some cool new features in this release and also lay some groundwork for the future:

  • “volumes from images” — this feature is addressed in the following two blueprints accepted for Folsom: creating volumes from images and efficient volumes from images. This feature allows for the creation of bootable volumes directly from glance images and is further used by the “boot from volume” feature of Nova.
  • Still TBD:  “multi volume backend”, which will allow users to take advantage of different storage providers with a single installation of Cinder. It is addressed in this blueprint and is still undergoing code review.

One of the Cinder project’s main roles is serving as the abstraction layer for different storage devices. Currently the following list of storage backends is supported, directly through their respective native APIs:

  • IBM Storwize V7000 unified storage system
  • IBM XIV Storage System series
  • NetApp onTap devices. Both the volume as a block device and the volume as a file on NFS are supported.
  • SheepDog storage system
  • SolidFire high performance SSD storages
  • NexentaStor Appliance

Cinder structure

Cinder consists of three basic services—Cinder API, Cinder scheduler, and Cinder volume, plus the underlying dedicated database.

OpenStack Cinder Storage Logical Block Diagram


Cinder API is a web service (providing a RESTful interface) responsible for handling user requests. In an OpenStack cluster, there can be many hosts that run the Cinder volume component. In order to load-balance volume creation between Cinder volumes, there is a Cinder scheduler component that implements this logic. The Cinder volume service is basically an abstraction layer to the different storage backends listed above.

Connection with the old nova-volume API

Despite migrating volume functionality to the separate project, Nova still supports volume management as originally implemented in the nova-volume component. Which approach to use is up to you when you install, but keep in mind that the plan is to completely remove volume management from Nova. By default Nova will use nova-volume, but it can be easily switched to Cinder by setting a flag:


The user is free to use the old, familiar “nova volume-*” commands, or can switch to the brand new “python-cinderclient.” These commands provide exactly the same behavior:

#creation of the volume sized 10 GB with python-cinderclient
cinder create --display_name vol0 10

#creation of the volume sized 10 GB with python-novaclient
nova volume-create --display_name vol0 10

Final observations

In sum, Cinder offers stability with respect to nova-volume features, but simplifies code maintainability. While that may be a disappointment to some who expect constant activity in new features, it’s really an important sign of maturity, as it opens the code base to broader innovation with greater depth in storage functionality.

Stay tuned for our upcoming post which will deal with high availability of API services in Openstack.

From Virtualization to Containerization
Learn how to move from monolithic to microservices in this free eBook
Download Now
Radio Cloud Native – Week of May 11th, 2022

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news. This week they discussed: Docker Extensions Artificial Intelligence shows signs that it's reaching the common person Google Cloud TPU VMs reach general availability Google buys MobileX, folds into Google Cloud NIST changes Palantir is back, and it's got a Blanket Purchase Agreement at the Department of Health and Human …

Radio Cloud Native – Week of May 11th, 2022
Where do Ubuntu 20.04, OpenSearch, Tungsten Fabric, and more all come together? In the latest Mirantis Container Cloud releases!

In the last several weeks we have released two updates to Mirantis Container Cloud - versions 2.16 and 2.17, which bring a number of important changes and enhancements. These are focused on both keeping key components up to date to provide the latest functionality and security fixes, and also delivering new functionalities for our customers to take advantage of in …

Where do Ubuntu 20.04, OpenSearch, Tungsten Fabric, and more all come together? In the latest Mirantis Container Cloud releases!
Monitoring Kubernetes costs using Kubecost and Mirantis Kubernetes Engine [Transcript]

Cloud environments & Kubernetes are becoming more and more expensive to operate and manage. In this demo-rich workshop, Mirantis and Kubecost demonstrate how to deploy Kubecost as a Helm chart on top of Mirantis Kubernetes Engine. Lens users will be able to visualize their Kubernetes spend directly in the Lens desktop application, allowing users to view spend and costs efficiently …

Monitoring Kubernetes costs using Kubecost and Mirantis Kubernetes Engine [Transcript]
Service Mesh for Mere Mortals
A Guide to Istio and How to Use Service Mesh Platforms
Technical training
Learn Kubernetes & OpenStack from Deployment Experts
Prep for certification!
View schedule
The Definitive Guide to Container Platforms