Atom feed of this document
Juno -  Juno -  Juno -  Juno -  Juno -  Juno -  Juno -  Juno - 

 Design and operation

  • Back-end: A term for a particular storage back-end. This could be iSCSI, NFS, NetApp, and so on.

  • Back-end-config: All the parameters required to connect to a specific back-end. For example, for NFS, this would be the server, path, and so on.

  • Flavor: This term is equivalent to volume "types". A user friendly term to specify some notion of quality of service. For example, "gold" might mean that the volumes use a back-end where backups are possible. A flavor can be associated with multiple back-ends. The volume scheduler, with the help of the driver, decides which back-end is used to create a volume of a particular flavor. Currently, the driver uses a simple "first-fit" policy, where the first back-end that can successfully create this volume is the one that is used.


The admin uses the nova-manage command detailed below to add flavors and back-ends.

One or more cinder-volume service instances are deployed for each availability zone. When an instance is started, it creates storage repositories (SRs) to connect to the back-ends available within that zone. All cinder-volume instances within a zone can see all the available back-ends. These instances are completely symmetric and hence should be able to service any create_volume request within the zone.

[Note]On XenServer, PV guests required

Note that when using XenServer you can only attach a volume to a PV guest.

Questions? Discuss on
Found an error? Report a bug against this page

loading table of contents...