Backend: A term for a particular storage backend. This could be iSCSI, NFS, Netapp etc.
Backend-config: All the parameters required to connect to a specific backend. For e.g. For NFS, this would be the server, path, etc.
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 will use a backend where backups are possible. A flavor can be associated with multiple backends. The volume scheduler, with the help of the driver, will decide which backend will be used to create a volume of a particular flavor. Currently, the driver uses a simple "first-fit" policy, where the first backend 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 backends.
One or more cinder service instances
will be deployed per availability zone. When
an instance is started, it will create storage
repositories (SRs) to connect to the backends
available within that zone. All cinder
instances within a zone can see all the
available backends. 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. |
