presented by mike perez
senior developer for DreamHost
•Maintain Cinder setup.
•Maintain interactions between
Nova and Cinder.
•Working with 900 Ceph OSD
setup comes out to around 4
•Contribute ﬁxes upstream.
cinder core developer
•Wrote the start of Cinder
•Cinder API documentation
•Cinder API references
•More code reviews than I
know what to do with
• project exists since Folsom release,
spun off Nova-volume
• cinder manages block storage
• not an object storage
• not a ﬁle level storage
• volumes attach to VM Instances
• boot from volume
• volumes have a lifecycle
independent of VM instance
Admin can create tiers of storage. e.g. two LVM
backends, one with SSD’s and the other with HDD’s.
•Users can specify a tier they want when creating a
•Create from image, snapshot
•Volume attach/detach (called by Nova)
•Manage volume types
•Transfer volumes from tenant to tenant
•Chooses which back-end to place a new volume on
•Conﬁgurable plugins for schedulers
•Filter scheduler has ﬁlters and weighers
•Filter scheduler Flow Example:
•Starts with list of all back-ends
•Filters according to capabilities
•Drivers report capabilities and state (e.g., free space)
•Sorts according to weights e.g., available free space
•Returns best candidate
•Drivers: Called by Manager, contains back-end-speciﬁc code
to communicate with various storage types (e.g., Linux LVM,
storage controllers from various vendors, distributed ﬁle
•Admin can run multiple cinder-volume instances, each with
its own conﬁguration ﬁle describing settings and the storage
•One cinder-volume instance can manage multiple back-ends
•Each back-end driver is generally conﬁgured to interact with
one storage pool
A backup is an archived copy of a Volume stored in a
•A backup is just the data that was written, unlike a
snapshot which is the entire block.
•Use Swift, Ceph, or IBM Tivoli Storage Manager
Nova calls Cinder via its API, passing connection information.
e.g., host name, iSCSI initiator name, FC WWNNs
Cinder API passes message to Cinder Volume.
Manager does initial error checking and calls volume driver.
Volume driver does any necessary preparation to allow the connection.
e.g., give the nova host permissions to access the volume.
Volume driver returns connection information, which is passed to Nova.
e.g., iSCSI iqn and portal, FC WWNN.
Nova creates the connection to the storage using the returned information.
Nova passes the volume device/file to the hypervisor.
Persistent Volume Data
Persistent Volume Control
•FC SAN Zone / Access Control
•Generic ZFS ISCSI
•HP Lefthand array iSCSI
•HP MSA 2040
•Get started with Cinder:
•REST API Docs:
•Thanks Avishay Traeger from IBM for letting me
copy things out of his slides.