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]](../common/images/admon/note.png) | On XenServer, PV guests required |
|---|---|
Note that when using XenServer you can only attach a volume to a PV guest. |
