The Xen Storage Manager volume driver (xensm) is a XenAPI hypervisor specific volume driver, and can be used to provide basic storage functionality, including volume creation and destruction, on a number of different storage back-ends. It also enables the capability of using more sophisticated storage back-ends for operations like cloning/snapshots, and so on. Some of the storage plug-ins that are already supported in Citrix XenServer and Xen Cloud Platform (XCP) are: NFS VHD: Storage repository (SR) plug-in that stores disks as Virtual Hard Disk (VHD) files on a remote Network File System (NFS). Local VHD on LVM: SR plug-in that represents disks as VHD disks on Logical Volumes (LVM) within a locally-attached Volume Group. HBA LUN-per-VDI driver: SR plug-in that represents Logical Units (LUs) as Virtual Disk Images (VDIs) sourced by host bus adapters (HBAs). For example, hardware-based iSCSI or FC support. NetApp: SR driver for mapping of LUNs to VDIs on a NETAPP server, providing use of fast snapshot and clone features on the filer. LVHD over FC: SR plug-in that represents disks as VHDs on Logical Volumes within a Volume Group created on an HBA LUN. For example, hardware-based iSCSI or FC support. iSCSI: Base ISCSI SR driver, provides a LUN-per-VDI. Does not support creation of VDIs but accesses existing LUNs on a target. LVHD over iSCSI: SR plug-in that represents disks as Logical Volumes within a Volume Group created on an iSCSI LUN. EqualLogic: SR driver for mapping of LUNs to VDIs on a EQUALLOGIC array group, providing use of fast snapshot and clone features on the array.

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 that when using XenServer you can only attach a volume to a PV guest.

xensm requires that you use either Citrix XenServer or XCP as the hypervisor. The NetApp and EqualLogic back-ends are not supported on XCP. Ensure all hosts running volume and Compute services have connectivity to the storage system. Set the following configuration options for the nova volume service: (nova-compute also requires the volume_driver configuration option.) --volume_driver "nova.volume.xensm.XenSMDriver" --use_local_volumes False You must create the back-end configurations that the volume driver uses before you start the volume service. $ nova-manage sm flavor_create <label> <description> $ nova-manage sm flavor_delete <label> $ nova-manage sm backend_add <flavor label> <SR type> [config connection parameters] SR type and configuration connection parameters are in keeping with the XenAPI Command Line Interface. $ nova-manage sm backend_delete <back-end-id> Example: For the NFS storage manager plug-in, run these commands: $ nova-manage sm flavor_create gold "Not all that glitters" $ nova-manage sm flavor_delete gold $ nova-manage sm backend_add gold nfs name_label=myback-end server=myserver serverpath=/local/scratch/myname $ nova-manage sm backend_remove 1 Start cinder-volume and nova-compute with the new configuration options. Currently, the flavors have not been tied to the volume types API. As a result, we simply end up creating volumes in a "first fit" order on the given back-ends. Use the standard euca-* or OpenStack API commands (such as volume extensions) to create, destroy, attach, or detach volumes.