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, etc. The list below shows some of the storage plugins already supported in Citrix XenServer and Xen Cloud Platform (XCP): NFS VHD: Storage repository (SR) plugin which stores disks as Virtual Hard Disk (VHD) files on a remote Network File System (NFS). Local VHD on LVM: SR plugin which represents disks as VHD disks on Logical Volumes (LVM) within a locally-attached Volume Group. HBA LUN-per-VDI driver: SR plugin which 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 plugin which 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 plugin which 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.

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 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 backend where backups are possible. A flavor can be associated with multiple backends. The volume scheduler, with the help of the driver, decides which backend is 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-volume service instances are deployed for each availability zone. When an instance is started, it creates storage repositories (SRs) to connect to the backends available within that zone. All cinder-volume 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 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 backends 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 The backend configurations that the volume driver uses need to be created before starting 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] Note: SR type and config connection parameters are in keeping with the XenAPI Command Line Interface. http://support.citrix.com/article/CTX124887 $ nova-manage sm backend_delete <backend-id> Example: For the NFS storage manager plugin, the steps below may be used. $ 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=mybackend 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 backends. The standard euca-* or OpenStack API commands (such as volume extensions) should be used for creating, destroying, attaching, or detaching volumes.