From c8ebbb8f80b61201cda8c55926708c5b32b3dc8f Mon Sep 17 00:00:00 2001 From: Avishay Traeger Date: Tue, 10 Sep 2013 09:05:28 +0300 Subject: [PATCH] Update Storwize/SVC driver documentation This update reflects changes made to the Storwize/SVC driver for the Havana release. Change-Id: I4de27ed8a6293efdb3c599e02e628184537910ba --- .../drivers/ibm-storwize-svc-driver.xml | 240 +++++++++++------- 1 file changed, 145 insertions(+), 95 deletions(-) diff --git a/doc/config-reference/block-storage/drivers/ibm-storwize-svc-driver.xml b/doc/config-reference/block-storage/drivers/ibm-storwize-svc-driver.xml index 4cb0a999c1..1518f7f26b 100644 --- a/doc/config-reference/block-storage/drivers/ibm-storwize-svc-driver.xml +++ b/doc/config-reference/block-storage/drivers/ibm-storwize-svc-driver.xml @@ -13,7 +13,7 @@ Network Configuration - The Storwize family or SVC system must be + The Storwize family or SVC system must be configured for iSCSI, Fibre Channel, or both. If using iSCSI, each Storwize family or SVC node should @@ -80,8 +80,8 @@ Configuring storage pools - The IBM Storwize/SVC driver allocates all volumes in a - single pool. + Each instance of the IBM Storwize/SVC driver allocates + all volumes in a single pool. The pool should be created in advance and be provided to the driver using the storwize_svc_volpool_name @@ -161,9 +161,7 @@ You can create an SSH key pair using OpenSSH, by running: - -ssh-keygen -t rsa - +$ ssh-keygen -t rsa The command prompts for a file to save the key pair. For example, if you select 'key' as the @@ -199,9 +197,7 @@ ssh-keygen -t rsa SVC driver by setting the volume_driver option in cinder.conf as follows: - -volume_driver = cinder.volume.drivers.storwize_svc.StorwizeSVCDriver - +volume_driver = cinder.volume.drivers.storwize_svc.StorwizeSVCDriver Configuring options for the Storwize family and @@ -213,10 +209,10 @@ volume_driver = cinder.volume.drivers.storwize_svc.StorwizeSVCDriver <table rules="all"> <caption>List of configuration flags for Storwize storage and SVC driver</caption> - <col width="35%"/> - <col width="15%"/> - <col width="15%"/> - <col width="35%"/> + <col width="40%"/> + <col width="10%"/> + <col width="12%"/> + <col width="38%"/> <thead> <tr> <td>Flag name</td> @@ -408,6 +404,16 @@ volume_driver = cinder.volume.drivers.storwize_svc.StorwizeSVCDriver </para></footnote> </para></td> </tr> + <tr> + <td><para> + <literal>storwize_svc_vol_iogrp</literal> + </para> + </td> + <td><para>Optional</para></td> + <td><para>0</para></td> + <td><para>The I/O group in which to allocate vdisks + </para></td> + </tr> <tr> <td><para> <literal>storwize_svc_flashcopy_timeout @@ -457,96 +463,94 @@ volume_driver = cinder.volume.drivers.storwize_svc.StorwizeSVCDriver </para></footnote> </para></td> </tr> + <tr> + <td><para> + <literal>storwize_svc_multihost_enabled + </literal> + </para> + </td> + <td><para>Optional</para></td> + <td><para>True</para></td> + <td><para>Enable mapping vdisks to multiple hosts + <footnote xml:id='storwize-svc-fn9'> + <para>This option allows the driver to map a vdisk + to more than one host at a time. This scenario + occurs during migration of a virtual machine + with an attached volume; the volume is + simultaneously mapped to both the source and + destination compute hosts. If your deployment + does not require attaching vdisks to multiple + hosts, setting this flag to False will provide + added safety. + </para></footnote> + </para></td> + </tr> </tbody> </table> </simplesect> <simplesect> - <title>Working with multiple back-ends - Cinder has support for multiple back-ends. This - can be accomplished by running multiple instances of - cinder-volume, each with its own configuration file, - or by including multiple sections in one configuration - file. For example: - -[DEFAULT] -... -enabled_backends = v7k1,v7k2 + Placement with volume types + The IBM Storwize/SVC driver exposes capabilities + that can be added to the extra specs + of volume types, and used by the filter scheduler to + determine placement of new volumes. Make sure to prefix + these keys with capabilities: to + indicate that the scheduler should use them. The following + extra specs are supported: -[v7k1] -... + + capabilities:volume_backend_name - Specify + a specific backend where the volume should be created. The + backend name is a contatenation of the name of the + IBM Storwize/SVC storage system as shown in + lssystem, an underscore, + and the name of the pool (mdisk group). For example: +capabilities:volume_backend_name=my7000_openstackpool + -[v7k2] -... - Here, - common options are placed under - [DEFAULT], while options - specific to a back-end are placed in the appropriate - section. + capabilities:compression_support - Specify + a backend according to compression support. A value of + True should be used to request a backend + that supports compression, and a value of + False will request a backend that does + not support compression. If you do not have constraints on + compression support, do not set this key. Note that + specifying True does not enable + compression; it only requests that the volume be placed on + a backend that supports compression. Example syntax: +capabilities:compression_support='<is> True' + - By default, volumes are allocated between back-ends - to balance allocated space. - However, volume types can be used to have - finer-grained control over where volumes are allocated. - Each volume type contains a set of key-value pairs called - extra specs. - Volume types are typically set a priori by an administrator, - and can be managed using the cinder client, using the - type-create, type-delete, - type-key, and type-list - arguments. + capabilities:easytier_support - Similar + semantics as the compression_support key, + but for specifying according to support of the Easy Tier + feature. Example syntax: +capabilities:easytier_support='<is> True' + - The extra specs keys which have the - "capabilities" prefix (called "scope") are interpreted by the - Cinder scheduler and used to make placement decisions according - to the capabilities of the available back-ends. - - The following are examples of supported key-values: - - - In the following example, the volume is placed on a - controller named myv7000, in a pool named - openstack: - -capabilities:volume_backend_name=my7000_openstack - - - In the next example, the volume is placed - on a controller that supports compression. Specifying - False requires that the volume is placed on a - back-end that does not support compression (if no - constraints on compression support are required, do - not set this key): - -capabilities:compression_support='<is> True' - - - The next example shows how Easy Tier support can be with - set with the same semantics as - compression_support: - -capabilities:easytier_support='<is> True' - - - The connection protocol used to attach volumes to - instances can also be specified using volume types. - In this example, the volume is placed on a controller - that supports Fibre Channel, and Fibre Channel is used - when attaching that volume. - FC can also be replaced with iSCSI. - -capabilities:storage_protocol='<in> FC' - + capabilities:storage_protocol - Specifies + the connection protocol used to attach volumes of this type + to instances. Legal values are iSCSI and + FC. This extra specs + value is used for both placement and setting the protocol + used for this volume. In the example syntax, note <in> + is used as opposed to <is> used in the previous + examples. +capabilities:storage_protocol='<in> FC' + + + Configuring per-volume creation options - The volume types previously described can also + Volume types can also be used to pass options to the IBM Storwize/SVC driver, which over-ride the default values set in the configuration file. Contrary to the previous examples where the "capabilities" scope was used to pass parameters to the Cinder scheduler, options can be passed to the IBM Storwize/SVC driver with the - "drivers" scope, or by omitting the scope. + "drivers" scope. The following extra specs keys are supported by the IBM Storwize/SVC driver: @@ -558,6 +562,7 @@ capabilities:storage_protocol='<in> FC' compression easytier multipath + iogrp These keys have the same semantics as their counterparts in the configuration file. They are set similarly; for example, @@ -566,15 +571,15 @@ capabilities:storage_protocol='<in> FC' - Complete volume type examples - In the following example, the volume is placed on - a controller named that supports Fibre Channel and - compression, FC is used when attaching the volume, - and compression is enabled: - -cinder type-create compressed -cinder type-key compressed set capabilities:storage_protocol=''<in> FC' capabilities:compression_support='<is> True' drivers:compression=True - + Example using volume types + In the following example, we create a volume type to specify + a controller that supports iSCSI and + compression, to use iSCSI when attaching the volume, + and and to enable compression: +$ cinder type-create compressed +$ cinder type-key compressed set capabilities:storage_protocol='<in> iSCSI' capabilities:compression_support='<is> True' drivers:compression=True + We can then create a 50GB volume using this type: +$ cinder create --display-name "compressed volume" --volume-type compressed 50 Volume types can be used, for example, to provide users with different @@ -596,4 +601,49 @@ cinder type-key compressed set capabilities:storage_protocol=''<in> FC' ca +
+ Operational Notes for the Storwize Family and SVC Driver + + Volume Migration + + In the context of OpenStack Block Storage's volume + migration feature, the IBM Storwize/SVC driver enables the + storage's virtualization technology. When migrating a + volume from one pool to another, the volume will appear + in the destination pool almost immediately, while the + storage moves the data in the background. + + + To enable this feature, both pools involved in + a given volume migration must have the same values + for extent_size. If the pools + have different values for + extent_size, the data will still + be moved directly between the pools (not host-side + copy), but the operation will be synchronous. + + + + + + Extending Volumes + + The IBM Storwize/SVC driver allows for extending a + volume's size, but only for volumes without snapshots. + + + + Snapshots and Clones + + Snapshots are implemented using FlashCopy with no + background copy (space-efficient). Volume clones + (volumes created from existing volumes) are implemented + with FlashCopy, but with background copy enabled. This + means that volume clones are independent, full copies. + While this background copy is taking place, attempting + to delete or extend the source volume will result in + that operation waiting for the copy to complete. + +
+