openstack-manuals/doc/config-reference/block-storage/drivers/xen-sm-driver.xml
Christian Berendt be95faee43 Standardize usage of client arguments (config-reference)
Like documented at https://wiki.openstack.org/wiki/Documentation/Conventions#Client_arguments:_.22--option_ARGUMENT.22
we prefer to use '--option ARGUMENT'.

Change-Id: Iea99bbd253ee4ced00ab9983c00ebc805e6e7568
2014-09-09 16:07:14 +02:00

199 lines
9.9 KiB
XML

<section xml:id="xensm" xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
<title>XenAPI Storage Manager volume driver</title>
<para>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:</para>
<orderedlist>
<listitem>
<para>NFS VHD: Storage repository (SR) plug-in that stores
disks as Virtual Hard Disk (VHD) files on a remote
Network File System (NFS).</para>
</listitem>
<listitem>
<para>Local VHD on LVM: SR plug-in that represents disks
as VHD disks on Logical Volumes (LVM) within a
locally-attached Volume Group.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>NetApp: SR driver for mapping of LUNs to VDIs on a
NETAPP server, providing use of fast snapshot and
clone features on the filer.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>iSCSI: Base ISCSI SR driver, provides a LUN-per-VDI.
Does not support creation of VDIs but accesses
existing LUNs on a target.</para>
</listitem>
<listitem>
<para>LVHD over iSCSI: SR plug-in that represents disks as
Logical Volumes within a Volume Group created on an
iSCSI LUN.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
</orderedlist>
<section xml:id="xensmdesign">
<title>Design and operation</title>
<simplesect>
<title>Definitions</title>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Back-end:</emphasis> A
term for a particular storage back-end. This
could be iSCSI, NFS, NetApp, and so on.</para>
</listitem>
<listitem>
<para><emphasis role="bold"
>Back-end-config:</emphasis> All the
parameters required to connect to a specific
back-end. For example, for NFS, this would be
the server, path, and so on.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Flavor:</emphasis>
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.</para>
</listitem>
</itemizedlist>
</simplesect>
<simplesect>
<title>Operation</title>
<para>The admin uses the nova-manage command detailed
below to add flavors and back-ends.</para>
<para>One or more <systemitem class="service"
>cinder-volume</systemitem> 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 <systemitem class="service"
>cinder-volume</systemitem> instances within a
zone can see all the available back-ends. These
instances are completely symmetric and hence should be
able to service any <literal>create_volume</literal>
request within the zone.</para>
<note>
<title>On XenServer, PV guests required</title>
<para>Note that when using XenServer you can only
attach a volume to a PV guest.</para>
</note>
</simplesect>
</section>
<section xml:id="xensmconfig">
<title>Configure XenAPI Storage Manager</title>
<simplesect>
<title>Prerequisites</title>
<orderedlist>
<listitem>
<para>xensm requires that you use either Citrix
XenServer or XCP as the hypervisor. The NetApp
and EqualLogic back-ends are not supported on
XCP.</para>
</listitem>
<listitem>
<para>Ensure all <emphasis role="bold"
>hosts</emphasis> running volume and
Compute services have connectivity to the
storage system.</para>
</listitem>
</orderedlist>
</simplesect>
<simplesect>
<title>Configuration</title>
<itemizedlist>
<listitem>
<para>
<emphasis role="bold">Set the following
configuration options for the nova volume
service: (<systemitem class="service"
>nova-compute</systemitem> also
requires the volume_driver configuration
option.)</emphasis>
</para>
<programlisting>
--volume_driver "nova.volume.xensm.XenSMDriver"
--use_local_volumes False
</programlisting>
</listitem>
<listitem>
<para>
<emphasis role="bold">You must create the
back-end configurations that the volume
driver uses before you start the volume
service.</emphasis>
</para>
<screen><prompt>$</prompt> <userinput>nova-manage sm flavor_create &lt;label> &lt;description></userinput>
<prompt>$</prompt> <userinput>nova-manage sm flavor_delete &lt;label></userinput>
<prompt>$</prompt> <userinput>nova-manage sm backend_add &lt;flavor label> &lt;SR type> [config connection parameters]</userinput></screen>
<note>
<para>SR type and configuration connection
parameters are in keeping with the <link
xlink:href="http://support.citrix.com/article/CTX124887"
>XenAPI Command Line
Interface</link>.</para>
</note>
<screen><prompt>$</prompt> <userinput>nova-manage sm backend_delete &lt;back-end-id></userinput></screen>
<para>Example: For the NFS storage manager
plug-in, run these commands:</para>
<screen><prompt>$</prompt> <userinput>nova-manage sm flavor_create gold "Not all that glitters"</userinput>
<prompt>$</prompt> <userinput>nova-manage sm flavor_delete gold</userinput>
<prompt>$</prompt> <userinput>nova-manage sm backend_add gold nfs name_label=myback-end server=myserver serverpath=/local/scratch/myname</userinput>
<prompt>$</prompt> <userinput>nova-manage sm backend_remove 1</userinput></screen>
</listitem>
<listitem>
<para>
<emphasis role="bold">Start <systemitem
class="service"
>cinder-volume</systemitem> and
<systemitem class="service"
>nova-compute</systemitem> with the
new configuration options.</emphasis>
</para>
</listitem>
</itemizedlist>
</simplesect>
<simplesect>
<title>Create and access the volumes from VMs</title>
<para>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.</para>
<para>Use the standard <command>euca-*</command> or
OpenStack API commands (such as volume extensions) to
create, destroy, attach, or detach volumes.</para>
</simplesect>
</section>
</section>