Cinder Block Storage service overview¶
The OpenStack Block Storage service (Cinder) adds persistent storage to a virtual machine. Block Storage provides an infrastructure for managing volumes, and interacts with OpenStack Compute to provide volumes for instances. The service also enables management of volume snapshots, and volume types.
The Block Storage service consists of the following components:
- cinder-api
Accepts API requests, and routes them to the
cinder-volumefor action.- cinder-volume
Interacts directly with the Block Storage service, and processes such as the
cinder-scheduler. It also interacts with these processes through a message queue. Thecinder-volumeservice responds to read and write requests sent to the Block Storage service to maintain state. It can interact with a variety of storage providers through a driver architecture.- cinder-scheduler daemon
Selects the optimal storage provider node on which to create the volume. A similar component to the
nova-scheduler.- cinder-backup daemon
The
cinder-backupservice provides backing up volumes of any type to a backup storage provider. Like thecinder-volumeservice, it can interact with a variety of storage providers through a driver architecture.- Messaging queue
Routes information between the Block Storage processes.
The default volume type¶
Since the Train release, it is required that each volume must have a
volume type, and thus the required configuration option
default_volume_type must have a value. A system-defined volume type
named __DEFAULT__ is created in the database during installation and
is the default value of the default_volume_type configuration option.
You (or your deployment tool) may wish to have a different volume type that is more suitable for your particular installation as the default type. This can be accomplished by creating the volume type you want using the Block Storage API, and then setting that volume type as the value for the configuration option. (The latter operation, of course, cannot be done via the Block Storage API.)
The system defined __DEFAULT__ volume type is a regular volume type
that may be updated or deleted. There is nothing special about it. It only
exists because there must always be at least one volume type in a cinder
deployment, and before the Block Storage API comes up, there is no way for
there to be a volume type unless the system creates it.
Given that since the Victoria release it is possible to set a default
volume type for any project, having a volume type named __DEFAULT__
in your deployment may be confusing to your users, leading them to think this
is the type that will be assigned while creating volumes (if the user doesn’t
specify one) or them specifically requesting __DEFAULT__ when creating a
volume instead of the actual configured default type for the system or their
project.
If you don’t wish to use the __DEFAULT__ type, you may delete it. The
Block Storage API will prevent deletion under these circumstances:
If
__DEFAULT__is the value of thedefault_volume_typeconfiguration option then it cannot be deleted. The solution is to make a different volume type the value of that configuration option.If there are volumes in the deployment of the
__DEFAULT__type, then it cannot be deleted. The solution is to retype those volumes to some other appropriate volume type.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.