openstack-manuals/doc/config-reference/block-storage/drivers/xen-sm-driver.xml
Don Domingo 20f780cd61 Apply service name conventions for Compute
There are several instances of "Compute Service" and "compute service"
in the upstream documentation. As was recently clarified in the docs
mailing list, these should be "Compute service/s". This patch corrects
all untagged instances inside normal <para> blocks.

Change-Id: Idcd7aafa0ce463e70635cb1c883a2476c1d97b5e
Partial-Bug: #1217503
2014-03-18 13:58:14 +10: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>