Pure Storage volume driver

Kilo - Kilo - Kilo - Kilo - Kilo - Kilo - Kilo - Kilo -

Limitations and known issues
Supported operations
Configure OpenStack and Purity

The Pure Storage FlashArray volume driver for OpenStack Block Storage interacts with configured Pure Storage arrays and supports various operations.

This driver can be configured in OpenStack Block Storage to work with the iSCSI storage protocol.

This driver is compatible with Purity FlashArrays that support the REST API (Purity 3.4.0 and newer) and that are capable of iSCSI connectivity. This release supports installation with OpenStack clusters running the Kilo version that use the KVM or QEMU hypervisors together with OpenStack Compute service's libvirt driver.

Limitations and known issues

If you do not set up the nodes hosting instances to use multipathing, all iSCSI connectivity will use a single physical 10-gigabit Ethernet port on the array. In addition to significantly limiting the available bandwidth, this means you do not have the high-availability and non-disruptive upgrade benefits provided by FlashArray.

Workaround: You must set up multipathing on your hosts.

Supported operations

Create, delete, attach, detach, retype, clone, and extend volumes.
Create a volume from snapshot.
Create, list, and delete volume snapshots.
Create, list, update, and delete consistency groups.
Create, list, and delete consistency group snapshots.
Manage and unmanage a volume.
Get volume statistics.
Create a thin provisioned volume.

Configure OpenStack and Purity

You need to configure both your Purity array and your OpenStack cluster.

	Note
	These instructions assume that the `cinder-api` and `cinder-scheduler` services are installed and configured in your OpenStack cluster.

Configure the OpenStack Block Storage service
In these steps, you will edit the cinder.conf file to configure OpenStack Block Storage service to enable multipathing and to use the Pure Storage FlashArray as back-end storage.
1. Retrieve an API token from Purity
  The OpenStack Block Storage service configuration requires an API token from Purity. Actions performed by the volume driver use this token for authorization. Also, Purity logs the volume driver's actions as being performed by the user who owns this API token.
  If you created a Purity user account that is dedicated to managing your OpenStack Block Storage volumes, copy the API token from that user account.
  Use the appropriate create or list command below to display and copy the Purity API token:
  - To create a new API token:
```
$ pureadmin create --api-token USER
```
    The following is an example output:
```
$ pureadmin create --api-token pureuser
Name      API Token                             Created
pureuser  902fdca3-7e3f-d2e4-d6a6-24c2285fe1d9  2014-08-04 14:50:30
```
  - To list an existing API token:
```
$ pureadmin list --api-token --expose USER
```
    The following is an example output:
```
$ pureadmin list --api-token --expose pureuser
Name      API Token                             Created
pureuser  902fdca3-7e3f-d2e4-d6a6-24c2285fe1d9  2014-08-04 14:50:30
```
2. Copy the API token retrieved (902fdca3-7e3f-d2e4-d6a6-24c2285fe1d9 from the examples above) to use in the next step.
3. Edit the OpenStack Block Storage service configuration file
  The following sample /etc/cinder/cinder.conf configuration lists the relevant settings for a typical Block Storage service using a single Pure Storage array:
```
[DEFAULT]
....
enabled_backends = puredriver-1
default_volume_type = puredriver-1
....

[puredriver-1]
volume_backend_name = puredriver-1
volume_driver = cinder.volume.drivers.pure.PureISCSIDriver
san_ip = IP_PURE_MGMT
pure_api_token = PURE_API_TOKEN
use_multipath_for_image_xfer = True
```
  Replace the following variables accordingly:
  IP_PURE_MGMT
  The IP address of the Pure Storage array's management interface or a domain name that resolves to that IP address.
  PURE_API_TOKEN
  The Purity Authorization token that the volume driver uses to perform volume management on the Pure Storage array.

	Note
	The volume driver automatically creates purity host objects for initiators as needed. If CHAP authentication is enabled via the `use_chap_auth` settting, you must ensure there are no manually created host objects with IQN's that will be used by the OpenStack Block Storage. The driver will only modify credentials on hosts that it manages.

Questions? Discuss on ask.openstack.org
Found an error? Report a bug against this page

Legal notices