From d86a2248f95d37674b61d5c6ef7c48e96b74ef53 Mon Sep 17 00:00:00 2001 From: Helen Walsh Date: Fri, 18 Oct 2019 19:52:09 +0100 Subject: [PATCH] PowerMax Docs - corrections and improvements 1. Corrections to PowerMaxOS versions 2. Clarifying licensing information 3. Clarifying upgrade scenarios 4. Formatting 5. Failover/failback clarification 6. Array OS support Change-Id: I9a7d4bb0810bf47f93eb0f82bfc0e99e7a939af5 (cherry picked from commit 5ccf4856c70742c5ad1f9a3986499c28ae4a5be7) --- .../drivers/dell-emc-powermax-driver.rst | 439 +++++++++--------- 1 file changed, 219 insertions(+), 220 deletions(-) diff --git a/doc/source/configuration/block-storage/drivers/dell-emc-powermax-driver.rst b/doc/source/configuration/block-storage/drivers/dell-emc-powermax-driver.rst index 9b4d2f60333..56666a20291 100644 --- a/doc/source/configuration/block-storage/drivers/dell-emc-powermax-driver.rst +++ b/doc/source/configuration/block-storage/drivers/dell-emc-powermax-driver.rst @@ -1,5 +1,5 @@ ====================================== -Dell EMC POWERMAX iSCSI and FC drivers +Dell EMC PowerMax iSCSI and FC drivers ====================================== The Dell EMC PowerMax drivers, ``PowerMaxISCSIDriver`` and @@ -37,9 +37,50 @@ Download Solutions Enabler and Unisphere from the Dell EMC's support web site and Configuration Guide`` and ``Dell EMC Unisphere for PowerMax Installation Guide`` at ``support.emc.com``. +.. note:: + + While it is not explicitly documented which OS versions should be + installed on a particular array, it is recommended to install the latest + PowerMax OS as supported by Unisphere for PowerMax, that the PowerMax + driver supports for a given OpenStack release. + + +-----------+------------------------+-------------+ + | OpenStack | Unisphere for PowerMax | PowerMax OS | + +===========+========================+=============+ + | Train | 9.1.x | 5978.444 | + +-----------+------------------------+-------------+ + | Stein | 9.0.x | 5978.221 | + +-----------+------------------------+-------------+ + + However, a Hybrid array can only run HyperMax OS 5977, and is still + supported until further notice. Some functionality will not be available + in older versions of the OS. If in any doubt, please contact your customer + representative. + + + Required PowerMax software suites for OpenStack ----------------------------------------------- +The storage system requires a Unisphere for PowerMax (SMC) eLicense. + +PowerMax +~~~~~~~~ +There are two licenses for the PowerMax 2000 and 8000: + +- Essentials software package +- Pro software package + +The Dell EMC PowerMax cinder driver requires the Pro software package. + +All Flash +~~~~~~~~~ +For full functionality including SRDF for the VMAX All Flash, the FX package, +or the F package plus the SRDF a la carte add on is required. + +Hybrid +~~~~~~ + There are five Dell EMC Software Suites sold with the VMAX Hybrid arrays: - Base Suite @@ -55,13 +96,11 @@ Suite and the Local Replication Suite) for the VMAX Hybrid. Using PowerMax Remote Replication functionality will also require the Remote Replication Suite. -For full functionality including SRDF for the VMAX All Flash, the FX package, -or the F package plus the SRDF ``a la carte`` add on is required. -The storage system also requires a Unisphere for PowerMax (SMC) eLicence. +.. note:: -Each are licensed separately. For further details on how to get the -relevant license(s), reference eLicensing Support below. + Each are licensed separately. For further details on how to get the + relevant license(s), reference eLicensing Support below. eLicensing support @@ -129,16 +168,9 @@ PowerMax drivers also support the following features: - Extending attached volume - Replicated volume retype support - Retyping attached(in-use) volume -- Unisphere high availability(HA) support +- Unisphere High Availability(HA) support - Online device expansion of a metro device -- Rapid tdev deallocation of deletes - -.. note:: - - VMAX All Flash array with Solutions Enabler 8.3.0.11 or later have - compression enabled by default when associated with Diamond Service Level. - This means volumes added to any newly created storage groups will be - compressed. +- Rapid TDEV deallocation of deletes PowerMax naming conventions @@ -156,8 +188,8 @@ PowerMax naming conventions 1. Perform md5 hash on the shortHostName 2. Convert output of 1. to hex 3. Take last 6 characters of shortHostName and append output of 2. - 4. If the length of output of 3. exceeds 16 characters - 5. Add the first 8 characters and last 8 characters together + 4. If the length of output of 3. exceeds 16 characters, join the + first 8 characters and last 8 characters. .. note:: @@ -171,8 +203,8 @@ PowerMax naming conventions 1. Perform md5 hash on the portgroup_name 2. Convert output of 1. to hex 3. Take last 6 characters of portgroup_name and append output of 2. - 4. If the length of output of 3. exceeds 12 characters - 5. Add the first 6 characters and last 6 characters together + 4. If the length of output of 3. exceeds 12 characters, join the + first 6 characters and last 6 characters. Masking view names @@ -180,7 +212,7 @@ Masking view names Masking views are dynamically created by the PowerMax FC and iSCSI drivers using the following naming conventions. ``[protocol]`` is either ``I`` for -volumes attached over iSCSI or ``F`` for volumes attached over Fiber Channel. +volumes attached over iSCSI or ``F`` for volumes attached over Fibre Channel. .. code-block:: text @@ -196,7 +228,7 @@ each new attach volume operation, the PowerMax driver retrieves the initiators (either WWNNs or IQNs) from OpenStack and adds or updates the contents of the Initiator Group as required. Names are of the following format. ``[protocol]`` is either ``I`` for volumes attached over iSCSI or ``F`` for volumes attached -over Fiber Channel. +over Fibre Channel. .. code-block:: console @@ -245,15 +277,16 @@ Child storage groups: .. note:: CD and RE are only set if compression is explicitly disabled or replication - explicitly enabled. See the compression and replication sections below. + explicitly enabled. See the compression `11. All Flash compression support`_ + and replication `Volume replication support`_ sections below. .. note:: For PowerMax and any All Flash with PowerMax OS (5978) or greater, workload - is NONE + if set will be ignored and set to NONE -PowerMax Driver Integration +PowerMax driver integration =========================== 1. Prerequisites @@ -286,7 +319,7 @@ PowerMax Driver Integration Configuration Guide`` at ``support.emc.com``. -2. FC Zoning with PowerMax +2. FC zoning with PowerMax -------------------------- Zone Manager is required when there is a fabric between the host and array. @@ -296,8 +329,8 @@ complex and open-zoning would raise security concerns. 3. iSCSI with PowerMax ---------------------- -- Make sure the ``iscsi-initiator-utils`` package is installed on all Compute - nodes. +- Make sure the ``open-iscsi`` package (or distro equivalent) is installed + on all Compute nodes. .. note:: @@ -305,15 +338,16 @@ complex and open-zoning would raise security concerns. masking view. An attach operation creates this masking view. -4. Configure Block Storage in cinder.conf + +4. Configure block storage in cinder.conf ----------------------------------------- .. note:: VMAX driver was rebranded to PowerMax in Stein, so some of the driver - specific tags have also changed. Legacy tags like vmax_srp, vmax_array, - vmax_service_level and vmax_port_group, as well as the old driver - location, will continue to work until the 'V' release. + specific tags have also changed. Legacy tags like ``vmax_srp``, + ``vmax_array``, ``vmax_service_level`` and ``vmax_port_group``, as well + as the old driver location, will continue to work until the 'V' release. .. config-table:: @@ -322,13 +356,6 @@ complex and open-zoning would raise security concerns. cinder.volume.drivers.dell_emc.powermax.common -.. note:: - - For security and backend uniformity, the use of the XML file for PowerMax - backend configuration was deprecated in Queens and removed entirely - in Rocky. - - .. note:: ``san_api_port`` is ``8443`` by default but can be changed if @@ -363,7 +390,7 @@ complex and open-zoning would raise security concerns. +--------------------+----------------------------+---------+----------+ -Configure Block Storage in cinder.conf +Configure block storage in cinder.conf Add the following entries to ``/etc/cinder/cinder.conf``: @@ -459,7 +486,7 @@ section describing unique parameters for connections, drivers and the ``cinder.conf`` backend stanza. -6. Create Volume Types +6. Create volume types ---------------------- Once the ``cinder.conf`` has been updated, :command:`openstack` commands @@ -515,15 +542,16 @@ associated with any service level). .. note:: - PowerMax and Hybrid support Optimized, Diamond, Platinum, Gold, Silver, - Bronze, and NONE service levels. VMAX All Flash supports Diamond and - None. Hybrid and All Flash support DSS_REP, DSS, OLTP_REP, OLTP, and None - workloads, the latter up until ucode 5977. Please refer to Stein PowerMax - online documentation if you wish to use ``workload``. There is no support + PowerMax and Hybrid support ``Optimized``, ``Diamond``, ``Platinum``, + ``Gold``, ``Silver``, ``Bronze``, and ``NONE`` service levels. VMAX + All Flash supports ``Diamond`` and `None. Hybrid and All Flash support + ``DSS_REP``, ``DSS``, ``OLTP_REP``, ``OLTP``, and None workloads, the + latter up until ucode 5977. Please refer to Stein PowerMax online + documentation if you wish to use ``workload``. There is no support for workloads in PowerMax OS (5978) or greater. -7. Interval and Retries +7. Interval and retries ----------------------- By default, ``interval`` and ``retries`` are ``3`` seconds and ``200`` retries @@ -554,32 +582,32 @@ Add the following lines to the PowerMax backend in the cinder.conf: interval = 1 retries = 700 -8. CHAP Authentication Support +8. CHAP authentication support ------------------------------ -This supports one way initiator CHAP authentication functionality into the +This supports one-way initiator CHAP authentication functionality into the PowerMax backend. With CHAP one-way authentication, the storage array challenges the host during the initial link negotiation process and expects to receive a valid credential and CHAP secret in response. When challenged, the host transmits a CHAP credential and CHAP secret to the storage array. -The storagearray looks for this credential and CHAP secret which stored in +The storage array looks for this credential and CHAP secret which stored in the host initiator's initiator group (IG) information in the ACLX database. Once a positive authentication occurs, the storage array sends an acceptance message to the host. However, if the storage array fails to find any record of the credential/secret pair, it sends a rejection message, and the link is closed. -Assumptions, Restrictions and Pre-Requisites +Assumptions, restrictions and prerequisites ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #. The host initiator IQN is required along with the credentials the host initiator will use to log into the storage array with. The same credentials should be used in a multi node system if connecting to the same array. -#. Enable one way CHAP authentication for the iscsi initiator on the storage +#. Enable one-way CHAP authentication for the iSCSI initiator on the storage array using SYMCLI. Template and example shown below. For the purpose of this setup, the credential/secret used would be my_username/my_password - with iscsi initiator of iqn.1991-05.com.company.lcseb130 + with iSCSI initiator of iqn.1991-05.com.company.lcseb130 .. code-block:: console @@ -593,7 +621,7 @@ Assumptions, Restrictions and Pre-Requisites -Settings and Configuration +Settings and configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~ #. Set the configuration in the PowerMax backend group in cinder.conf using the @@ -765,8 +793,8 @@ Prerequisites - PowerMax Volume is created against volume type and QoS is enforced with the parameters above. -USE CASE 2 - Preset limits -~~~~~~~~~~~~~~~~~~~~~~~~~~ +USE CASE 2 - Pre-set limits +~~~~~~~~~~~~~~~~~~~~~~~~~~~ Prerequisites - PowerMax @@ -889,8 +917,8 @@ The output of the command contains the xml below. It is found between the -USE CASE 3 - Preset limits -~~~~~~~~~~~~~~~~~~~~~~~~~~ +USE CASE 3 - Pre-set limits +~~~~~~~~~~~~~~~~~~~~~~~~~~~ Prerequisites - PowerMax @@ -1145,7 +1173,10 @@ uncompressed. .. note:: This feature is only applicable for All Flash arrays, 250F, 450F, 850F - and 950F and PowerMax 2000 and 8000. + and 950F and PowerMax 2000 and 8000. It was first introduced Solutions + Enabler 8.3.0.11 or later and is enabled by default when associated with + a Service Level. This means volumes added to any newly created storage + groups will be compressed. Use case 1 - Compression disabled create, attach, detach, and delete volume ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1195,7 +1226,7 @@ Please refer to the following: :doc:`/admin/blockstorage-over-subscription`. -13. Live Migration support +13. Live migration support -------------------------- Non-live migration (sometimes referred to simply as 'migration'). The instance @@ -1222,7 +1253,7 @@ Architecture In PowerMax, A volume cannot belong to two or more FAST storage groups at the same time. To get around this limitation we leverage both cascaded storage -groups and a temporary non FAST storage group. +groups and a temporary non-FAST storage group. A volume can remain 'live' if moved between masking views that have the same initiator group and port groups which preserves the host path. @@ -1236,7 +1267,7 @@ on the volume: #. The volume is added to the FAST storage group within the destination parent storage group of the destination masking view. At this point the volume belongs to two storage groups. -#. One of two things happens: +#. One of two things happen: - If the connection to the destination instance is successful, the volume is removed from the non-FAST storage group in the originating masking @@ -1251,11 +1282,12 @@ Live migration configuration Please refer to the following for more information: -https://docs.openstack.org/nova/latest/admin/live-migration-usage.html +https://docs.openstack.org/nova/latest/admin/configuring-migrations.html and -https://docs.openstack.org/nova/latest/admin/configuring-migrations.html +https://docs.openstack.org/nova/latest/admin/live-migration-usage.html + .. note:: @@ -1326,7 +1358,7 @@ For our use case shown below, we have three hosts with host names HostA, HostB and HostC. HostA is the compute node while HostB and HostC are the compute nodes. The following were also used in live migration. -- 2 gb bootable volume using the cirros image. +- 2 gb bootable volume using the CirrOS image. - Instance created using the 2gb volume above with a flavor m1.small using 2048 RAM, 20GB of Disk and 1 VCPU. @@ -1390,7 +1422,7 @@ hosts/servers simultaneously. Please see :doc:`/admin/blockstorage-volume-multiattach` for configuration information. -Multi-attach Architecture +Multi-attach architecture ~~~~~~~~~~~~~~~~~~~~~~~~~ In PowerMax, a volume cannot belong to two or more FAST storage groups at the @@ -1405,7 +1437,7 @@ no service level, workload, or SRP specified). backend is required – the volume is attached to and detached from each host as normal. -Example Use Case +Example use case ~~~~~~~~~~~~~~~~ Volume ``Multi-attach-Vol-1`` (with a multi-attach capable volume type, and @@ -1435,21 +1467,22 @@ We then decide to detach the volume from ‘Multi-attach-Instance-B’ on HostB: storage group. The non-FAST managed storage group is cleaned up, if required. -.. note:: - Known issue - the multi-attach flag is still false after a retype. This - is being addressed in https://bugs.launchpad.net/cinder/+bug/1790840 - - -15. Volume Encryption support +15. Volume encryption support ----------------------------- Please refer to the following: :doc:`/configuration/block-storage/volume-encryption`. -16. Volume metadata in logs ---------------------------- +16. Volume metadata +------------------- + +Volume metadata is returned to the user in both the Cinder Volume logs and +with volumes and snapshots created in Cinder via the UI or CLI. + +16.1 Volume metadata in logs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If debug is enabled in the default section of the cinder.conf, PowerMax Cinder driver will log additional volume information in the Cinder volume log, @@ -1485,7 +1518,36 @@ PowerMax view point. | serial_number | 000123456789 | +------------------------------------+---------------------------------------------------------+ -17. Unisphere high availability(HA) support +16.2 Metadata in the UI and CLI +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By default metadata will be set on all volume and snapshot objects created in +Cinder. This information represents the state of the object on the backend +PowerMax and will change when volume attributes are changed by performing +actions on them such as re-type or attaching to an instance. + +.. code-block:: console + + demo@openstack-controller:~$ cinder show powermax-volume + + +--------------------------------+------------------------------------------------------------+ + | Property | Value | + +--------------------------------+------------------------------------------------------------+ + | metadata | ArrayID : 000123456789 | + | | ArrayModel : PowerMax_8000 | + | | CompressionDisabled : False | + | | Configuration : TDEV | + | | DeviceID : 0012F | + | | DeviceLabel : OS-d87edb98-60fd-49dd-bb0f-cc388cf6f3f4 | + | | Emulation : FBA | + | | ReplicationEnabled : False | + | | ServiceLevel : Diamond | + | | Workload : None | + | name | powermax-volume | + +--------------------------------+------------------------------------------------------------+ + + +17. Unisphere High Availability(HA) support ------------------------------------------- This feature facilitates high availability of Unisphere for PowerMax servers, @@ -1564,7 +1626,7 @@ restarted for changes to take effect. used by the PowerMax driver. -18. Rapid TDEV Deallocation +18. Rapid TDEV deallocation --------------------------- The PowerMax driver can now leverage the enhanced volume delete feature-set @@ -1579,7 +1641,7 @@ compliant volume deletion sequence based on the connected PowerMax array’s metadata. -19. PowerMax Online (in-use) Device Expansion +19. PowerMax online (in-use) device expansion --------------------------------------------- .. table:: @@ -1589,27 +1651,27 @@ metadata. +----------------+----------------+--------------+--------------+-------------+ | R1 uCode Level | R2 uCode Level | Sync | Async | Metro | +================+================+==============+==============+=============+ - | 5979 | 5979 | Y | Y | Y | + | 5978.444 | 5978.444 | Y | Y | Y | +----------------+----------------+--------------+--------------+-------------+ - | 5979 | 5978 | Y | Y | N | + | 5978.444 | 5978.221 | Y | Y | N | +----------------+----------------+--------------+--------------+-------------+ - | 5978 | 5978 | Y | Y | N | + | 5978.221 | 5978.221 | Y | Y | N | +----------------+----------------+--------------+--------------+-------------+ -Assumptions, Restrictions and Pre-Requisites -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Assumptions, restrictions and prerequisites +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - ODE in the context of this document refers to extending a volume where it is in-use, that is, attached to an instance. - The ``allow_extend`` is only applicable on Hybrid arrays or All Flash arrays with HyperMax OS. If included elsewhere, it is ignored. - Extending a Metro volume is blocked for all replication sessions where both - R1 and R2 arrays are not PowerMax OS 5979 or newer. + R1 and R2 arrays are not PowerMax OS 5978.444 or newer. - Where one array is a lower uCode than the other, the environment is limited - to functionality of that of the lowest uCode level, i.e. if R1 is 5979 and - R2 is 5978, expanding a metro volume is not supported, both R1 and R2 need - to be on 5979 uCode. + to functionality of that of the lowest uCode level, i.e. if R1 is 5978.444 + and R2 is 5978.221, expanding a metro volume is not supported, both R1 and + R2 need to be on 5978.444 uCode. Cinder supported operations =========================== @@ -1690,7 +1752,7 @@ Configure the source and target arrays * ``remote_port_group`` is the name of a PowerMax port group that has been pre-configured to expose volumes managed by this backend in the event - of a failover. Make sure that this portgroup contains either all FC or + of a failover. Make sure that this port group contains either all FC or all iSCSI port groups (for a given back end), as appropriate for the configured driver (iSCSI or FC). @@ -1749,7 +1811,7 @@ Configure the source and target arrays ``replication_device`` parameter has been entered in the PowerMax backend entry in the ``cinder.conf``, a corresponding volume type needs to be created ``replication_enabled`` property set. See - above ``Setup PowerMax drivers`` for details. + above `6. Create volume types`_ for details. .. code-block:: console @@ -1791,6 +1853,11 @@ Most features are supported, except for the following: Failover host ~~~~~~~~~~~~~ +.. note:: + + Failover and Failback operations are not applicable in Metro + configurations. + In the event of a disaster, or where there is required downtime, upgrade of the primary array for example, the administrator can issue the failover host command to failover to the configured target: @@ -1799,22 +1866,38 @@ host command to failover to the configured target: # cinder failover-host cinder_host@POWERMAX_FC_REPLICATION -If the primary array becomes available again, you can initiate a failback -using the same command and specifying ``--backend_id default``: +After issuing Cinder failover-host command Cinder will set the R2 array as the +target array for Cinder, however to get existing instances to use this new +array and paths to volumes it is necessary to first shelve Nova instances and +then unshelve them, this will effectively restart the Nova instance and +re-establish data paths between Nova instances and the volumes on the R2 array. + +.. code-block:: console + + # nova shelve + # nova unshelve [--availability-zone ] + +When a host is in failover mode performing normal volume or snapshot +provisioning will not be possible, failover-host mode simply provides access +to replicated volumes to minimise environment down-time. The primary objective +whilst in failover mode should be to get the R1 array back online. When the +primary array becomes available again, you can initiate a failback using the +same failover command and specifying --backend_id default: .. code-block:: console # cinder failover-host cinder_host@POWERMAX_FC_REPLICATION --backend_id default -.. note:: +After issuing the failover command to revert to the default backend host it is +necessary to re-issue the Nova shelve and unshelve commands to restore the +data paths between Nova instances and their corresponding back end volumes. +Once reverted to the default backend volume and snapshot provisioning +operations can continue as normal. - Failover and Failback operations are not applicable in Metro configurations. - - -Asynchronous and Metro replication management groups +Asynchronous and metro replication management groups ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Asynchronous and Metro volumes in an RDF session, i.e. belonging to an SRDF +Asynchronous and metro volumes in an RDF session, i.e. belonging to an SRDF group, must be managed together for RDF operations (although there is a ``consistency exempt`` option for creating and deleting pairs in an Async group). To facilitate this management, we create an internal RDF management @@ -1827,7 +1910,7 @@ group. For this reason, it is imperative that the RDF group specified in the Metro support ~~~~~~~~~~~~~ -SRDF/Metro is a High Availabilty solution. It works by masking both sides of +SRDF/Metro is a high availability solution. It works by masking both sides of the RDF relationship to the host, and presenting all paths to the host, appearing that they all point to the one device. In order to do this, there needs to be multipath software running to manage writing to the @@ -1854,7 +1937,7 @@ Known issues replication volume type. -Volume retype - storage assisted volume migration +Volume retype - storage assisted volume migration -------------------------------------------------- Volume retype with storage assisted migration is supported now for @@ -1866,7 +1949,7 @@ retype, follow these steps: another, use volume retype with the migration-policy to on-demand. The target volume type should have the same volume_backend_name configured and should have the desired pool_name to which you are trying to retype to - (please refer to ``Setup PowerMax Drivers`` for details). + (please refer to `6. Create volume types`_ for details). .. code-block:: console @@ -1884,7 +1967,7 @@ retype, follow these steps: .. note:: - With the Stein release, In Use (attached) volume retype is supported + With the Stein release, in-use (attached) volume retype is supported Generic volume group support @@ -1944,7 +2027,7 @@ without failing over the entire host. See below for usage. A generic volume group can be both consistent group snapshot enabled and consistent group replication enabled. -Storage Group Names +Storage group names ~~~~~~~~~~~~~~~~~~~ Storage groups are created on the PowerMax as a result of creation of generic @@ -1956,113 +2039,22 @@ name. TruncatedGroupName_GroupUUID or GroupUUID -Group type operations -~~~~~~~~~~~~~~~~~~~~~ +Group type, group and group snapshot operations +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Create a group type - -.. code-block:: console - - cinder --os-volume-api-version 3.11 group-type-create GROUP_TYPE - -- Show a group type - -.. code-block:: console - - cinder --os-volume-api-version 3.11 group-type-show GROUP_TYPE - -- List group types - -.. code-block:: console - - cinder --os-volume-api-version 3.11 group-type-list - -- Delete group type - -.. code-block:: console - - cinder --os-volume-api-version 3.11 group-type-delete GROUP_TYPE - -- Set/unset a group spec - -.. code-block:: console - - cinder --os-volume-api-version 3.11 group-type-key GROUP_TYPE set consistent_group_snapshot_enabled=" True" - -- List group types and group specs: - -.. code-block:: console - - cinder --os-volume-api-version 3.11 group-specs-list - -Group operations -~~~~~~~~~~~~~~~~ - -- Create a group: - -.. code-block:: console - - cinder --os-volume-api-version 3.13 group-create --name GROUP GROUP_TYPE VOLUME_TYPE1,VOLUME_TYPE2 - -- Show a group: - -.. code-block:: console - - cinder --os-volume-api-version 3.13 group-show GROUP - -- List all groups: - -.. code-block:: console - - cinder --os-volume-api-version 3.13 group-list - -- Create a volume and add it to a group at the time of creation: - -.. code-block:: console - - cinder --os-volume-api-version 3.13 create --volume-type VOLUME_TYPE1 --group-id GROUP_ID 1 - -- Modify a group to add or remove volumes: - -.. code-block:: console - - cinder --os-volume-api-version 3.13 group-update --add-volumes UUID1,UUID2 --remove-volumes UUID3,UUID4 GROUP - -- Delete a group - -.. code-block:: console - - cinder --os-volume-api-version 3.13 group-delete --delete-volumes GROUP - -Group snapshot operations -~~~~~~~~~~~~~~~~~~~~~~~~~ - -- Create a group snapshot: - -.. code-block:: console - - cinder --os-volume-api-version 3.14 group-snapshot-create --name GROUP_SNAPSHOT GROUP - -- Delete group snapshot(s): - -.. code-block:: console - - cinder --os-volume-api-version 3.14 group-snapshot-delete GROUP_SNAPSHOT - -- Create a group from a group snapshot: - -.. code-block:: console - - $ cinder --os-volume-api-version 3.14 group-create-from-src --group-snapshot GROUP_SNAPSHOT --name GROUP - -- Create a group from a source snapshot: - -.. code-block:: console - - $ cinder --os-volume-api-version 3.14 group-create-from-src --source-group SOURCE_GROUP --name GROUP +Please refer to the following section for the most up to date group type +group and group replication operations https://docs.openstack.org/cinder/latest/admin/blockstorage-groups.html Group replication operations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Generic volume group operations no longer require the user to specify the +Cinder CLI version, however, performing generic volume group replication +operations still require this setting. When running generic volume group +commands set the value --os-volume-api-version to 3.38. +These commands are not listed in the latest Cinder CLI documentation so +will remain here until added to the latest Cinder CLI version or +deprecated from Cinder. + - Enable group replication @@ -2090,7 +2082,7 @@ Group replication operations --secondary-backend-id default -Manage and Unmanage Volumes +Manage and unmanage Volumes --------------------------- Managing volumes in OpenStack is the process whereby a volume which exists @@ -2110,7 +2102,7 @@ OpenStack, the following prerequisites must be met: - The volume must a whole GB e.g. 5.5GB is not a valid size -- The volume cannot be a snapvx target +- The volume cannot be a SnapVX target For a volume to exist in a Cinder managed pool, it must reside in the same @@ -2137,7 +2129,7 @@ the same format: - The PowerMax serial number (12 digit numerical) -Manage Volumes +Manage volumes ~~~~~~~~~~~~~~ With your pool name defined you can now manage the volume into OpenStack, this @@ -2171,7 +2163,7 @@ the same way as any other OpenStack PowerMax volume. PowerMax driver on a manage operation. -Managing Volumes with Replication Enabled +Managing volumes with replication enabled ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Whilst it is not possible to manage volumes into OpenStack that are part of a @@ -2183,7 +2175,7 @@ volume type as the chosen volume type. Once managed, replication will be enabled for that volume. -Unmanage Volume +Unmanage volume ~~~~~~~~~~~~~~~ Unmanaging a volume is not the same as deleting a volume. When a volume is @@ -2212,7 +2204,7 @@ the 'OS-' prefix has been removed, this is another visual indication that the volume is no longer managed by OpenStack. -Manage/Unmanage Snapshots +Manage/unmanage snapshots ------------------------- Users can manage PowerMax SnapVX snapshots into OpenStack if the source volume @@ -2231,7 +2223,7 @@ Set-up, restrictions and requirements: #. It is only possible to manage or unmanage one snapshot at a time in Cinder. -Manage SnapVX Snapshot +Manage SnapVX snapshot ~~~~~~~~~~~~~~~~~~~~~~ It is possible to manage PowerMax SnapVX snapshots into OpenStack, where the @@ -2247,7 +2239,7 @@ the restriction around managing SnapVX source volumes has been removed. or volumes which exist in a replication session. -Requirements/Restrictions: +Requirements/restrictions: #. The SnapVX source volume must be present in and managed by Cinder. @@ -2259,7 +2251,7 @@ Requirements/Restrictions: linked target volumes. -Command Structure: +Command structure: #. Identify your SnapVX snapshot for management on the PowerMax, note the name. @@ -2321,7 +2313,7 @@ snapshot in this example named ``OS-PowerMaxSnapshot``. The associated snapshot managed by Cinder will be present for use under the name ``SnapshotManaged``. -Unmanage Cinder Snapshot +Unmanage cinder snapshot ~~~~~~~~~~~~~~~~~~~~~~~~ Unmanaging a snapshot in Cinder is the process whereby the snapshot is removed @@ -2386,7 +2378,7 @@ List manageable volume is filtered by: - Volume should not be ``encapsulated`` - Volume should not be ``reserved`` - Volume should not be a part of an RDF session -- Volume should not be a snapVX Target +- Volume should not be a SnapVX Target - Volume identifier should not begin with ``OS-``. Manageable snaphots @@ -2411,7 +2403,7 @@ List manageable snapshots is filtered by: There is some delay in the syncing of the Unisphere for PowerMax database when the state/properties of a volume is modified using ``symcli``. To - prevent this it is preferrable to modify state/properties of volumes within + prevent this it is preferable to modify state/properties of volumes within Unisphere. @@ -2430,10 +2422,17 @@ Upgrading from SMI-S based driver to RESTAPI based driver Seamless upgrades from an SMI-S based driver to RESTAPI based driver, following the setup instructions above, are supported with a few exceptions: -#. Live migration functionality will not work on already attached/in-use - legacy volumes. These volumes will first need to be detached and reattached - using the RESTAPI based driver. This is because we have changed the masking - view architecture from Pike to better support this functionality. +#. OpenStack's ``live migration`` functionality will not work on already + attached/in-use legacy volumes without first migrating the volumes to + the new REST masking view structure. This can be done by running the + migrate.py script in PyU4V. Please refer to the Tools Guide in PyU4V_. + + .. code-block:: text + + $ pip install PyU4V + #. Consistency groups are deprecated in Pike. Generic Volume Groups are supported from Pike onwards. + +.. _PyU4V: https://pyu4v.readthedocs.io/en/latest/