Nimble Storage volume driver¶

Supported operations¶

• Create, delete, clone, attach, and detach volumes
• Create and delete volume snapshots
• Create a volume from a snapshot
• Copy an image to a volume
• Copy a volume to an image
• Extend a volume
• Get volume statistics
• Manage and unmanage a volume
• Enable encryption and default performance policy for a volume-type extra-specs
• Force backup of an in-use volume.

Nimble Storage driver configuration¶

Update the file /etc/cinder/cinder.conf with the given configuration.

In case of a basic (single back-end) configuration, add the parameters within the [default] section as follows.

[default]
san_ip = NIMBLE_MGMT_IP
san_login = NIMBLE_USER
san_password = NIMBLE_PASSWORD
use_multipath_for_image_xfer = True
volume_driver = NIMBLE_VOLUME_DRIVER

In case of multiple back-end configuration, for example, configuration which supports multiple Nimble Storage arrays or a single Nimble Storage array with arrays from other vendors, use the following parameters.

[default]
enabled_backends = Nimble-Cinder

[Nimble-Cinder]
san_ip = NIMBLE_MGMT_IP
san_login = NIMBLE_USER
san_password = NIMBLE_PASSWORD
use_multipath_for_image_xfer = True
volume_driver = NIMBLE_VOLUME_DRIVER
volume_backend_name = NIMBLE_BACKEND_NAME

In case of multiple back-end configuration, Nimble Storage volume type is created and associated with a back-end name as follows.

$ openstack volume type create NIMBLE_VOLUME_TYPE
$ openstack volume type set --property volume_backend_name=NIMBLE_BACKEND_NAME NIMBLE_VOLUME_TYPE

This section explains the variables used above:

NIMBLE_MGMT_IP

Management IP address of Nimble Storage array/group.

NIMBLE_USER

Nimble Storage account login with minimum power user (admin) privilege if RBAC is used.

NIMBLE_PASSWORD

Password of the admin account for nimble array.

NIMBLE_VOLUME_DRIVER

Use either cinder.volume.drivers.nimble.NimbleISCSIDriver for iSCSI or cinder.volume.drivers.nimble.NimbleFCDriver for Fibre Channel.

NIMBLE_BACKEND_NAME

A volume back-end name which is specified in the cinder.conf file. This is also used while assigning a back-end name to the Nimble volume type.

NIMBLE_VOLUME_TYPE

The Nimble volume-type which is created from the CLI and associated with NIMBLE_BACKEND_NAME.

Note

Restart the cinder-api, cinder-scheduler, and cinder-volume services after updating the cinder.conf file.

Nimble driver extra spec options¶

The Nimble volume driver also supports the following extra spec options:

‘nimble:encryption’=’yes’

Used to enable encryption for a volume-type.

‘nimble:perfpol-name’=PERF_POL_NAME

PERF_POL_NAME is the name of a performance policy which exists on the Nimble array and should be enabled for every volume in a volume type.

‘nimble:multi-initiator’=’true’

Used to enable multi-initiator access for a volume-type.

nimble:dedupe’=’true’

Used to enable dedupe support for a volume-type.

‘nimble:iops-limit’=IOPS_LIMIT

Used to set the IOPS_LIMIT between 256 and 4294967294 for all volumes created for this volume-type.

‘nimble:folder’=FOLDER_NAME

FOLDER_NAME is the name of the folder which exists on the Nimble array and should be enabled for every volume in a volume type

These extra-specs can be enabled by using the following command:

$ openstack volume type set --property KEY=VALUE VOLUME_TYPE

VOLUME_TYPE is the Nimble volume type and KEY and VALUE are the options mentioned above.

Configuration options¶

The Nimble storage driver supports these configuration options:

Multipathing¶

In OpenStack environments where Cinder block device multipathing is desired there are a few things to consider.

Configuring mulitpathing varies by system depending on the environment. In a scenario where solely Nimble devices are being created by Cinder, the following /etc/multipath.conf file may be used:

defaults {
    user_friendly_names yes
    find_multipaths     no
}

blacklist {
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^hd[a-z]"
    device {
        vendor  ".*"
        product ".*"
    }
}

blacklist_exceptions {
    device {
        vendor  "Nimble"
        product "Server"
    }
}

devices {
    device {
        vendor               "Nimble"
        product              "Server"
        path_grouping_policy group_by_prio
        prio                 "alua"
        hardware_handler     "1 alua"
        path_selector        "service-time 0"
        path_checker         tur
        features             "1 queue_if_no_path"
        no_path_retry        30
        failback             immediate
        fast_io_fail_tmo     5
        dev_loss_tmo         infinity
        rr_min_io_rq         1
        rr_weight            uniform
    }
}

After making changes to /etc/multipath.conf, the multipath subsystem needs to be reconfigured:

# multipathd reconfigure

Nova needs to be configured to pickup the actual multipath device created on the host.

In /etc/nova/nova.conf, add the following to the [libvirt] section:

[libvirt]
volume_use_multipath = True

After editing the Nova configuration file, the nova-conductor service needs to be restarted.

To validate that instances get properly connected to the multipath device, inspect the instance devices:

# virsh dumpxml <Instance ID | Instance Name | Instance UUID>