ZTE volume drivers¶

System requirements¶

To use the ZTE drivers, the following prerequisites:

• ZTE KS3200 or KU5200 array with:
  • iSCSI or FC interfaces
  • 30B2 firmware or later
• Network connectivity between the OpenStack host and the array management interfaces
• HTTPS or HTTP must be enabled on the array

Supported operations¶

• Create, delete, attach, and detach volumes.
• Create, list, and delete volume snapshots.
• Create a volume from a snapshot.
• Copy an image to a volume.
• Copy a volume to an image.
• Clone a volume.
• Extend a volume.
• Migrate a volume with back-end assistance.
• Retype a volume.
• Manage and unmanage a volume.

Configuring the array¶

1. Verify that the array can be managed using an HTTPS connection. HTTP can also be used if zte_api_protocol=http is placed into the appropriate sections of the cinder.conf file.

   Confirm that virtual pools A and B are present if you plan to use virtual pools for OpenStack storage.

2. Edit the cinder.conf file to define a storage back-end entry for each storage pool on the array that will be managed by OpenStack. Each entry consists of a unique section name, surrounded by square brackets, followed by options specified in key=value format.

   • The zte_backend_name value specifies the name of the storage pool on the array.
   • The volume_backend_name option value can be a unique value, if you wish to be able to assign volumes to a specific storage pool on the array, or a name that is shared among multiple storage pools to let the volume scheduler choose where new volumes are allocated.
   • The rest of the options will be repeated for each storage pool in a given array: the appropriate cinder driver name, IP address or host name of the array management interface; the username and password of an array user account with manage privileges; and the iSCSI IP addresses for the array if using the iSCSI transport protocol.

   In the examples below, two back ends are defined, one for pool A and one for pool B, and a common volume_backend_name. Use this for a single volume type definition can be used to allocate volumes from both pools.

   Example: iSCSI back-end entries

   [pool-a]
   zte_backend_name = A
   volume_backend_name = zte-array
   volume_driver = cinder.volume.drivers.zte.zte_iscsi.ZTEISCSIDriver
   san_ip = 10.1.2.3
   san_login = manage
   san_password = !manage
   zte_iscsi_ips = 10.2.3.4,10.2.3.5
   
   [pool-b]
   zte_backend_name = B
   volume_backend_name = zte-array
   volume_driver = cinder.volume.drivers.zte.zte_iscsi.ZTEISCSIDriver
   san_ip = 10.1.2.3
   san_login = manage
   san_password = !manage
   zte_iscsi_ips = 10.2.3.4,10.2.3.5
   

   Example: Fibre Channel back end entries

   [pool-a]
   zte_backend_name = A
   volume_backend_name = zte-array
   volume_driver = cinder.volume.drivers.zte.zte_fc.ZTEFCDriver
   san_ip = 10.1.2.3
   san_login = manage
   san_password = !manage
   
   [pool-b]
   zte_backend_name = B
   volume_backend_name = zte-array
   volume_driver = cinder.volume.drivers.zte.zte_fc.ZTEFCDriver
   san_ip = 10.1.2.3
   san_login = manage
   san_password = !manage
   

3. If HTTPS is not enabled in the array, include zte_api_protocol = http in each of the back-end definitions.

4. If HTTPS is enabled, you can enable certificate verification with the option zte_verify_certificate=True. You may also use the zte_verify_certificate_path parameter to specify the path to a CA_BUNDLE file containing CAs other than those in the default list.

5. Modify the [DEFAULT] section of the cinder.conf file to add an enabled_backends parameter specifying the back-end entries you added, and a default_volume_type parameter specifying the name of a volume type that you will create in the next step.

   Example: [DEFAULT] section changes

   [DEFAULT]
   # ...
   enabled_backends = pool-a,pool-b
   default_volume_type = zte
   

6. Create a new volume type for each distinct volume_backend_name value that you added to the cinder.conf file. The example below assumes that the same volume_backend_name=zte-array option was specified in all of the entries, and specifies that the volume type zte can be used to allocate volumes from any of them.

   Example: Creating a volume type

   $ openstack volume type create zte
   $ openstack volume type set --property volume_backend_name=zte-array zte
   

7. After modifying the cinder.conf file, restart the cinder-volume service.

Driver-specific options¶

The following table contains the configuration options that are specific to the ZTE drivers.