← Back to branch summary

~ubuntu-branches/ubuntu/raring/nova/raring-proposed

« back to all changes in this revision

Viewing changes to doc/source/devref/xensmvolume.rst

  • Committer: Package Import Robot
  • Author(s): Chuck Short, Adam Gandelman, Chuck Short
  • Date: 2012-11-23 09:04:58 UTC
  • mfrom: (1.1.66)
  • Revision ID: package-import@ubuntu.com-20121123090458-91565o7aev1i1h71
Tags: 2013.1~g1-0ubuntu1
https://launchpad.net/bugs/1073289
https://launchpad.net/bugs/1076442
[ Adam Gandelman ]
* debian/control: Ensure novaclient is upgraded with nova,
  require python-keystoneclient >= 1:2.9.0. (LP: #1073289)
* debian/patches/{ubuntu/*, rbd-security.patch}: Dropped, applied
  upstream.
* debian/control: Add python-testtools to Build-Depends.

[ Chuck Short ]
* New upstream version.
* Refreshed debian/patches/avoid_setuptools_git_dependency.patch.
* debian/rules: FTBFS if missing binaries.
* debian/nova-scheudler.install: Add missing rabbit-queues and
  nova-rpc-zmq-receiver.
* Remove nova-volume since it doesnt exist anymore, transition to cinder-*.
* debian/rules: install apport hook in the right place.
* debian/patches/ubuntu-show-tests.patch: Display test failures.
* debian/control: Add depends on genisoimage
* debian/control: Suggest guestmount.
* debian/control: Suggest websockify. (LP: #1076442)
* debian/nova.conf: Disable nova-volume service.
* debian/control: Depend on xen-system-* rather than the hypervisor.
* debian/control, debian/mans/nova-conductor.8, debian/nova-conductor.init,
  debian/nova-conductor.install, debian/nova-conductor.logrotate
  debian/nova-conductor.manpages, debian/nova-conductor.postrm
  debian/nova-conductor.upstart.in: Add nova-conductor service.
* debian/control: Add python-fixtures as a build deps.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/source/devref/xensmvolume.rst
1
 
Xen Storage Manager Volume Driver
2
 
=================================
3
 
 
4
 
The Xen Storage Manager (xensm) driver for Nova-Volume is based on XenAPI Storage Manager. This will not only provide basic storage functionality (like volume creation, and destruction) on a number of different storage back-ends, such as Netapp, NFS, etc. but it will also enable the capability of using more sophisticated storage back-ends for operations like cloning/snapshotting etc. To have an idea of the benefits of using XenAPI SM to provide back-end storage services, the list below shows some of the storage plugins already supported in XenServer/XCP:
5
 
 
6
 
-   NFS VHD: SR plugin which stores disks as VHD files on a remote NFS filesystem
7
 
-   Local VHD on LVM: SR plugin which represents disks as VHD disks on Logical Volumes within a locally-attached Volume Group
8
 
-   HBA LUN-per-VDI driver: SR plugin which represents LUNs as VDIs sourced by hardware HBA adapters, e.g. hardware-based iSCSI or FC support
9
 
-   NetApp: SR driver for mapping of LUNs to VDIs on a NETAPP server, providing use of fast snapshot and clone features on the filer
10
 
-   LVHD over FC: SR plugin which represents disks as VHDs on Logical Volumes within a Volume Group created on an HBA LUN, e.g. hardware-based iSCSI or FC support
11
 
-   iSCSI: Base ISCSI SR driver, provides a LUN-per-VDI. Does not support creation of VDIs but accesses existing LUNs on a target.
12
 
-   LVHD over iSCSI: SR plugin which represents disks as Logical Volumes within a Volume Group created on an iSCSI LUN
13
 
-   EqualLogic: SR driver for mapping of LUNs to VDIs on an EQUALLOGIC array group, providing use of fast snapshot and clone features on the array 
14
 
 
15
 
Glossary
16
 
=========
17
 
 
18
 
    XenServer: Commercial, supported product from Citrix
19
 
 
20
 
    Xen Cloud Platform (XCP): Open-source equivalent of XenServer (and the development project for the toolstack). Everything said about XenServer below applies equally to XCP
21
 
 
22
 
    XenAPI: The management API exposed by XenServer and XCP
23
 
 
24
 
    xapi: The primary daemon on XenServer and Xen Cloud Platform; the one that exposes the XenAPI 
25
 
 
26
 
 
27
 
Design
28
 
=======
29
 
 
30
 
Definitions
31
 
-----------
32
 
 
33
 
Backend: A term for a particular storage backend. This could be iSCSI, NFS, Netapp etc.
34
 
Backend-config: All the parameters required to connect to a specific backend. For e.g. For NFS, this would be the server, path, etc.
35
 
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.
36
 
 
37
 
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.
38
 
 
39
 
Operation
40
 
----------
41
 
 
42
 
Using the nova-manage command detailed in the implementation, an admin can add flavors and backends.
43
 
 
44
 
One or more nova-volume 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 nova-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.
45
 
 
46
 
 
47
 
Commands
48
 
=========
49
 
 
50
 
A category called "sm" has been added to nova-manage in the class StorageManagerCommands.
51
 
 
52
 
The following actions will be added:
53
 
 
54
 
-    flavor_list
55
 
-    flavor_create
56
 
-    flavor_delete
57
 
-    backend_list
58
 
-    backend_add
59
 
-    backend_remove 
60
 
 
61
 
Usage:
62
 
------
63
 
 
64
 
nova-manage sm flavor_create <label> <description>
65
 
 
66
 
nova-manage sm flavor_delete<label>
67
 
 
68
 
nova-manage sm backend_add <flavor label> <SR type> [config connection parameters]
69
 
 
70
 
Note: SR type and config connection parameters are in keeping with the Xen Command Line Interface. http://support.citrix.com/article/CTX124887
71
 
 
72
 
nova-manage sm backend_delete <backend-id>
73
 
 
74
 
Examples:
75
 
---------
76
 
 
77
 
nova-manage sm flavor_create gold "Not all that glitters"
78
 
 
79
 
nova-manage sm flavor_delete gold
80
 
 
81
 
nova-manage sm backend_add gold nfs name_label=toybox-renuka server=myserver serverpath=/local/scratch/myname
82
 
 
83
 
nova-manage sm backend_remove 1
84
 
 
85
 
API Changes
86
 
===========
87
 
 
88
 
No API changes have been introduced so far. The existing euca-create-volume and euca-delete-volume commands (or equivalent OpenStack API commands) should be used.