# HPE Storage Configurations

## Overview

HPE storage arrays provide enterprise-grade block storage solutions for data centers. Private Cloud Director supports the following HPE storage arrays:

* **HPE 3PAR and Primera** - Enterprise block storage over Fibre Channel and iSCSI using the HPE 3PAR driver.
* **HPE Alletra 9000/10000** - High-end block storage using the same HPE 3PAR driver over Fibre Channel and iSCSI.
* **HPE Nimble (HPE Alletra 5000/6000)** - Predictive analytics-driven storage over Fibre Channel and iSCSI using the HPE Nimble driver.

{% hint style="info" %}
**NOTE**

HPE 3PAR, Primera, and Alletra 9000/10000 arrays use the same driver family (hpe\_3par), which provides consistent configuration and management across these models. They support thin provisioning, deduplication, and compression (DECO) for volumes 16 GiB and larger. HPE Nimble and Alletra 5000/6000 arrays use a separate driver (hpe\_nimble); see the Nimble tabs for configuration details.
{% endhint %}

Select a storage array and protocol below to view the complete configuration steps for your environment.

{% tabs %}
{% tab title="HPE 3PAR/Primera - Fibre Channel " %}
HPE 3PAR and Primera arrays use the same driver and configuration parameters for Fibre Channel connectivity, providing high-performance block storage for enterprise workloads.

**Prerequisites**

Before you configure the 3PAR/Primera Fibre Channel backend, complete these requirements:

* Minimum 3PAR OS version: 3.2.1 or later.
* Supported Primera models: A650 and A670.
* Install Fibre Channel HBAs on all hosts.
* Enable the Web Services API (WSAPI) on the 3PAR/Primera array. <code class="expression">space.vars.product\_name</code>uses WSAPI to programmatically manage volumes, snapshots, and CPG operations.
* Create a Common Provisioning Group (CPG) on the array. Platform9 provisions all volumes from the specified CPG.
* Configure FC zoning between hosts and the 3PAR/Primera array. Proper zoning ensures hosts can discover and access storage LUNs.

**Volume backend configuration**

```ini
[hpe_3par_fc_backend]
volume_driver = cinder.volume.drivers.hpe.hpe_3par_fc.HPE3PARFCDriver
volume_backend_name = hpe_3par_fc
san_ip = <3PAR_MGMT_IP>
san_login = <3PAR_USER>
san_password = <3PAR_PASSWORD>
hpe3par_api_url = https://<3PAR_MGMT_IP>/api/v1
hpe3par_username = <3PAR_USER>
hpe3par_password = <3PAR_PASSWORD>
hpe3par_cpg = <CPG_NAME>
hpe3par_debug = false
# Persona 2 configures volumes for generic ALUA hosts (recommended)
hpe3par_persona = 2
use_multipath_for_image_xfer = true
volumes_dir = /opt/pf9/etc/pf9-cindervolume-base/volumes/
```

**Configuration parameters**

* **hpe3par\_persona** Configures the host type for volume attachments. Set to `2` for generic ALUA hosts, which is recommended for most deployments. This ensures proper multipath failover behavior.
* **use\_multipath\_for\_image\_xfer** Enables multipath for image transfers, improving reliability during volume creation from images.

**Image management configuration**

To enable a storage backend for image uploads, add the following parameters:

```ini
allowed_direct_url_schemes = cinder
image_upload_use_cinder_backend = true
verify_glance_signatures = false
```

**Optional parameters**

Enable image-volume caching when you use a storage backend for image storage. Caching stores converted images locally on each storage host, which reduces image transfer time for subsequent volume creation requests.

```ini
image_volume_cache_enabled = true
image_volume_cache_max_count = 50
image_volume_cache_max_size_gb = 200
```

**Configuration notes**

* These arrays support thin provisioning with deduplication and compression (DECO) for volumes 16 GiB and larger.
* The system thin-provisions volumes smaller than 16 GiB without DECO.
  {% endtab %}

{% tab title="HPE 3PAR/Primera - iSCSI" %}
HPE 3PAR and Primera arrays provide block storage over IP networks through iSCSI, offering flexible connectivity using standard Ethernet infrastructure.

**Prerequisites**

Before you configure the 3PAR/Primera iSCSI backend, complete these requirements:

* Minimum 3PAR OS version: 3.2.1 or later.
* Supported Primera models: A650 and A670.
* Install `open-iscsi` on all hosts. The iSCSI initiator enables hosts to discover and connect to iSCSI targets.
* Enable the Web Services API (WSAPI) on the 3PAR/Primera array. Platform9 uses WSAPI to programmatically manage volumes, snapshots, and CPG operations.
* Create a Common Provisioning Group (CPG) on the array. Platform9 provisions all volumes from the specified CPG.
* Enable iSCSI ports on the array and verify network connectivity.
* Configure iSCSI connectivity between hosts and the array. Verify hosts can reach all iSCSI portal IPs.

**Volume backend configuration**

```ini
[hpe_3par_iscsi_backend]
volume_driver = cinder.volume.drivers.hpe.hpe_3par_iscsi.HPE3PARISCSIDriver
volume_backend_name = hpe_3par_iscsi
san_ip = <3PAR_MGMT_IP>
san_login = <3PAR_USER>
san_password = <3PAR_PASSWORD>
hpe3par_api_url = https://<3PAR_MGMT_IP>/api/v1
hpe3par_username = <3PAR_USER>
hpe3par_password = <3PAR_PASSWORD>
hpe3par_cpg = <CPG_NAME>
# Comma-separated list of iSCSI portal IPs for multipath
hpe3par_iscsi_ips = <ISCSI_IP_1>,<ISCSI_IP_2>
hpe3par_debug = false
use_multipath_for_image_xfer = true
volumes_dir = /opt/pf9/etc/pf9-cindervolume-base/volumes/
```

**Configuration parameters**

* **hpe3par\_iscsi\_ips** Comma-separated list of iSCSI portal IP addresses. Specify multiple IPs for multipath redundancy and higher availability.
* **use\_multipath\_for\_image\_xfer** Enables multipath for image transfers, improving reliability during volume creation from images.

**Configuration notes**

* Verify all iSCSI IPs are accessible from hypervisor hosts before configuring the backend.
* Configure CHAP authentication for additional security if required.
* These arrays support thin provisioning with DECO for volumes 16 GiB and larger.
  {% endtab %}

{% tab title="HPE Alletra - Fibre Channel " %}
HPE Alletra 9000 and 10000 series arrays use the same driver and API as HPE 3PAR and Primera, providing modern enterprise storage with Fibre Channel connectivity.

**Prerequisites**

Before you configure the Alletra Fibre Channel backend, complete these requirements:

* Install Fibre Channel HBAs on all hosts.
* Enable Web Services API (WSAPI) on the Alletra array. Platform9 uses WSAPI to programmatically manage volumes, snapshots, and CPG operations.
* Create a Common Provisioning Group (CPG) on the array. Platform9 provisions all volumes from the specified CPG.
* Configure FC zoning between hosts and the Alletra array. Proper zoning ensures hosts can discover and access storage LUNs.

**Volume backend configuration**

```ini
[alletra_fc_backend]
volume_driver = cinder.volume.drivers.hpe.hpe_3par_fc.HPE3PARFCDriver
volume_backend_name = alletra_fc
san_ip = <ALLETRA_MGMT_IP>
san_login = <ALLETRA_USER>
san_password = <ALLETRA_PASSWORD>
hpe3par_api_url = https://<ALLETRA_MGMT_IP>/api/v1
hpe3par_username = <ALLETRA_USER>
hpe3par_password = <ALLETRA_PASSWORD>
hpe3par_cpg = <CPG_NAME>
hpe3par_debug = false
# Persona 2 configures volumes for generic ALUA hosts (recommended)
hpe3par_persona = 2
use_multipath_for_image_xfer = true
volumes_dir = /opt/pf9/etc/pf9-cindervolume-base/volumes/
```

**Configuration parameters**

* **hpe3par\_persona** Configures the host type for volume attachments. Set to `2` for generic ALUA hosts, which is recommended for most deployments. This ensures proper multipath failover behavior.
* **use\_multipath\_for\_image\_xfer** Enables multipath for image transfers, improving reliability during volume creation from images.

**Image management configuration**

To enable a storage backend for image uploads, add the following parameters:

```ini
allowed_direct_url_schemes = cinder
image_upload_use_cinder_backend = true
verify_glance_signatures = false
```

**Optional parameters**

Enable image-volume caching when you use a storage backend for image storage. Caching stores converted images locally on each storage host, which reduces image transfer time for subsequent volume creation requests.

```ini
image_volume_cache_enabled = true
image_volume_cache_max_count = 50
image_volume_cache_max_size_gb = 200
```

**Configuration notes**

* Configuration parameters are identical to 3PAR/Primera.
* Alletra 9000 uses the same API endpoints as 3PAR.
* These arrays support thin provisioning with DECO compression for volumes 256MB
* The system thin-provisions volumes smaller than 16 GiB without DECO.
  {% endtab %}

{% tab title="HPE Alletra - iSCSI" %}
HPE Alletra 9000 and 10000 series arrays provide block storage over iSCSI using the same driver as HPE 3PAR and Primera.

**Prerequisites**

Before you configure the Alletra iSCSI backend, complete these requirements:

* Install `open-iscsi` on all hosts. The iSCSI initiator enables hosts to discover and connect to iSCSI targets.
* Enable Web Services API (WSAPI) on the Alletra array. <code class="expression">space.vars.product\_name</code> uses WSAPI to programmatically manage volumes, snapshots, and CPG operations.
* Create a Common Provisioning Group (CPG) on the array. <code class="expression">space.vars.product\_name</code> provisions all volumes from the specified CPG.
* Enable iSCSI ports on the array and verify network connectivity.
* Configure iSCSI connectivity between hosts and the array. Verify hosts can reach all iSCSI portal IPs.

**Volume backend configuration**

```ini
[alletra_iscsi_backend]
volume_driver = cinder.volume.drivers.hpe.hpe_3par_iscsi.HPE3PARISCSIDriver
volume_backend_name = alletra_iscsi
san_ip = <ALLETRA_MGMT_IP>
san_login = <ALLETRA_USER>
san_password = <ALLETRA_PASSWORD>
hpe3par_api_url = https://<ALLETRA_MGMT_IP>/api/v1
hpe3par_username = <ALLETRA_USER>
hpe3par_password = <ALLETRA_PASSWORD>
hpe3par_cpg = <CPG_NAME>
# Comma-separated list of iSCSI portal IPs for multipath
hpe3par_iscsi_ips = <ISCSI_IP_1>,<ISCSI_IP_2>
hpe3par_debug = false
use_multipath_for_image_xfer = true
volumes_dir = /opt/pf9/etc/pf9-cindervolume-base/volumes/
```

**Configuration parameters**

* **hpe3par\_iscsi\_ips** Comma-separated list of iSCSI portal IP addresses. Specify multiple IPs for multipath redundancy and higher availability.
* **use\_multipath\_for\_image\_xfer** Enables multipath for image transfers, improving reliability during volume creation from images.

**Configuration notes**

* Configuration parameters are identical to 3PAR/Primera iSCSI.
* These arrays support thin provisioning with DECO compression for volumes 16 GiB and larger.
* The system thin-provisions volumes smaller than 16 GiB without DECO.
  {% endtab %}

{% tab title="HPE Nimble - iSCSI" %}
HPE Nimble arrays provide predictive analytics-driven storage with built-in replication and space-efficient snapshots. <code class="expression">space.vars.product\_name</code> supports Nimble arrays through the Nimble driver using iSCSI.

**Prerequisites**

Before you configure the Nimble iSCSI backend, complete these requirements:

* Install `open-iscsi` on all hosts. The iSCSI initiator enables hosts to discover and connect to iSCSI targets.
* Verify the Nimble array management interface is accessible from <code class="expression">space.vars.product\_name</code>control plane hosts.
* Create a storage pool on the array. <code class="expression">space.vars.product\_name</code> provisions all volumes from the specified pool.
* Configure iSCSI connectivity between hosts and the array. Verify hosts can reach the Nimble iSCSI network.

**Volume backend configuration**

```ini
[nimble_iscsi_backend]
volume_driver = cinder.volume.drivers.hpe.nimble.NimbleISCSIDriver
volume_backend_name = nimble_iscsi
san_ip = <NIMBLE_MGMT_IP>
san_login = <NIMBLE_USER>
san_password = <NIMBLE_PASSWORD>
nimble_pool_name = <POOL_NAME>
use_multipath_for_image_xfer = true
```

**Configuration parameters**

* **nimble\_pool\_name** Specifies the storage pool name on the Nimble array where Platform9 provisions volumes.
* **use\_multipath\_for\_image\_xfer** Enables multipath for image transfers, improving reliability during volume creation from images.

**Volume type configuration**

Nimble requires specific extra specifications for the volume type of encrypted volumes and for performance policies.

**For encrypted volumes:**

Enable encryption at the volume-type level using the `nimble:encryption` attribute:

```ini
nimble:encryption = yes
```

{% hint style="warning" %}
Nimble encrypted volumes require the `nimble:encryption = yes` attribute in the volume type. If you omit this attribute, volume allocation to encrypted pools fails with unclear error messages.
{% endhint %}

**For performance policies:**

To assign a specific performance policy, add the following extra spec to the volume type:

```ini
nimble:perfpol-name = <PERFORMANCE_POLICY_NAME>
```

Example performance policies available on Nimble arrays:

* SQL Server 2012
* Exchange 2010
* VMware
* Default

**Configuration notes**

* Performance policies are predefined on the Nimble array and must exist before you reference them in volume types.
* Nimble supports automatic compression and space reclamation without additional configuration.
* Snapshots are instant and crash-consistent, enabling rapid backup and recovery workflows.
  {% endtab %}

{% tab title="HPE Nimble - Fibre Channel" %}
HPE Nimble arrays, sold as HPE Alletra 5000 and 6000 in current product lines, provide predictive analytics-driven storage with built-in replication and space-efficient snapshots. Private Cloud Director supports Nimble arrays through the Nimble driver using Fibre Channel.

#### Prerequisites

Complete the following before you configure the Nimble Fibre Channel backend.

**Fabric and array side**

* Install Fibre Channel HBAs on all hypervisor hosts.
* Configure FC zoning between host HBA WWPNs and Nimble target WWPNs on the SAN switches. Zoning is **not** automated by the Nimble driver and must be in place before LUNs can be discovered.
* Enable FC at the Nimble group level. Confirm with `group --info` that `FC enabled: Yes`.
* Create a storage pool on the array. Private Cloud Director provisions all volumes from the specified pool.
* Use a Nimble account with at least power-user privilege.
* Do not pre-create initiator groups for the host WWPNs. The driver automatically creates and manages igroups pre-existing igroups for the same WWPNs, causing membership conflicts.

**Network**

* Ensure the Private Cloud Director control plane can reach the Nimble management IP on **TCP/5392**. The driver uses the Nimble REST API directly; no external SDK is required.

**Compute host packages**

* On RHEL 9: `dnf install device-mapper-multipath sg3_utils sysfsutils`, then `mpathconf --enable && systemctl enable --now multipathd`.
* On Ubuntu 22.04 or later: `apt install multipath-tools sg3-utils sysfsutils`, then `systemctl enable --now multipathd`.
* HBA kernel modules (`lpfc` for Emulex, `qla2xxx` for QLogic/Marvell) ship with both distributions and load automatically.
* `iscsid` is not required for pure FC deployments.

{% hint style="danger" %}
**NOTE**

Do not install the HPE Nimble Linux Toolkit (NLT) on compute hosts. OpenStack Cinder is not compatible with NLT.
{% endhint %}

#### **Volume backend configuration**

```ini
[nimble_fc_backend]
volume_driver = cinder.volume.drivers.hpe.nimble.NimbleFCDriver
volume_backend_name = nimble_fc
san_ip = <NIMBLE_MGMT_IP>
san_login = <NIMBLE_USER>
san_password = <NIMBLE_PASSWORD>
nimble_pool_name = <POOL_NAME>
nimble_verify_certificate = false
use_multipath_for_image_xfer = true
enforce_multipath_for_image_xfer = true
```

Add the backend to `enabled_backends` in the `[DEFAULT]` section:

```ini
[DEFAULT]
enabled_backends = nimble_fc_backend
```

Restart `cinder-api`, `cinder-scheduler`, and `cinder-volume` after applying configuration changes. Verify the backend is registered with `cinder service-list`.

**Configuration parameters**

* **nimble\_pool\_name** Specifies the storage pool name on the Nimble array where Private Cloud Director provisions volumes. Use `default` if the array uses the default pool.
* **nimble\_verify\_certificate** Controls TLS certificate verification when Private Cloud Director connects to the Nimble management API. Set to `true` for production deployments that use trusted certificates.
* **nimble\_verify\_cert\_path** Path to the CA bundle used to verify the Nimble management certificate. Required only when `nimble_verify_certificate = true`. Omit the parameter when certificate verification is disabled. Example: `nimble_verify_cert_path = /etc/pki/tls/certs/nimble-ca.pem`.
* **use\_multipath\_for\_image\_xfer** Enables multipath for image transfers, improving reliability during volume creation from images.
* **enforce\_multipath\_for\_image\_xfer** Requires multipath connectivity for image transfers and fails the operation if multipath is not available. Set to `true` to ensure that volume operations never fall back to a single path.

{% hint style="warning" %}
**NOTE**

Set `nimble_verify_cert_path` only to a valid filesystem path or omit it. The driver treats the value as a literal path; placeholder strings such as `none` cause certificate loading to fail when verification is enabled.
{% endhint %}

**Compute host configuration**

To enable multipath for volume attachments on hypervisor hosts, add the following to `nova_override.conf`:

```ini
[libvirt]
volume_use_multipath = true
volume_enforce_multipath = true
```

`volume_enforce_multipath` is available in 2025.1 Epoxy and later. When enabled, `nova-compute` fails to start if `multipathd` is not running, which prevents silent fallback to single-path attachments. It requires `volume_use_multipath = true`.

Restart `nova-compute` on each hypervisor after applying changes.

**Multipath configuration**

Configure `/etc/multipath.conf` on all hypervisor and storage hosts. The following defaults and blacklist configuration is recommended for Nimble FC deployments:

```ini
defaults {
    find_multipaths     yes
    user_friendly_names no
    polling_interval    10
}

blacklist {
    wwid <WWID_OF_LOCAL_DISK>
}
```

After editing `multipath.conf`, run `multipathd reconfigure`.

**Configuration notes**

* Set `find_multipaths` to `yes` so multipath creates a device only when at least two non-blacklisted paths exist with the same WWID. Setting it to `no` causes multipath to wrap every non-blacklisted path, including local disks with single paths.
* Add the WWID of each host's local boot disk to the `blacklist {}` block. This prevents multipath from managing local disks as if they were LUNs from external storage. To find the WWID of a local disk, run `/usr/lib/udev/scsi_id -g -u -d /dev/<disk>` on the host.

**Optional: device-specific tuning**

For deployments that require fine-grained control over Nimble device behavior, add a `devices {}` block to `multipath.conf` with Nimble-specific settings:

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

This block is not required. Default multipath behavior is sufficient for most Nimble FC deployments. Notes on selected values:

* `fast_io_fail_tmo 5` matches the HPE Nimble Linux Integration Guide. The value applies during FC RSCN events.
* `no_path_retry 30` queues I/O for approximately 150 seconds before failing. Use `queue` for indefinite queueing only when host shutdown behavior under total path loss is acceptable.
* `rr_min_io_rq 1` is the request-based equivalent of the deprecated `rr_min_io`. The legacy key is silently ignored on RHEL 6.2 and later kernels.
* `hardware_handler "1 alua"` is functionally redundant on RHEL 8/9 and Ubuntu 20.04 or later because `scsi_dh_alua` is auto-attached by the kernel. The line is preserved for explicitness.

#### **Volume type configuration**

After the backend is enabled, create a volume type and bind it to `volume_backend_name`:

```bash
openstack volume type create nimble_fc
openstack volume type set --property volume_backend_name=nimble_fc nimble_fc
```

In multi-backend deployments, this binding is mandatory. Without it, the scheduler returns "No valid host was found" when users request volumes for the Nimble backend.

Nimble supports volume-type extra specifications for encrypted volumes and performance policies. These specifications apply to both iSCSI and Fibre Channel backends.

**For encrypted volumes**

Enable encryption at the volume-type level using the `nimble:encryption` attribute:

```ini
nimble:encryption = yes
```

{% hint style="warning" %}
**NOTE**

Nimble encrypted volumes require the `nimble:encryption = yes` attribute in the volume type. If you omit this attribute, volume allocation to encrypted pools fails with unclear error messages.
{% endhint %}

**For performance policies**

To assign a specific performance policy, add the following extra spec to the volume type:

```ini
nimble:perfpol-name = <PERFORMANCE_POLICY_NAME>
```

Performance policies are predefined on the Nimble array and must exist before you reference them in volume types.

**Multi-attach volumes**

For multi-attach support, set the standard `multiattach` capability on the volume type. The legacy `nimble:multi-initiator` extra spec is no longer parsed by the driver and must not be used.

**Verification**

After applying the storage role, verify the configuration on a hypervisor:

* `systemctl is-active multipathd` returns `active`.
* `multipath -ll` lists Nimble LUNs with multiple paths grouped by priority.
* `cinder service-list` shows `cinder-volume@nimble_fc_backend` as `up`.
* A test volume created against the `nimble_fc` volume type attaches to an instance and appears as `/dev/dm-N` inside the guest.

**Additional notes**

* Nimble supports automatic compression and space reclamation without additional configuration.
* Snapshots are instant and crash-consistent, enabling rapid backup and recovery workflows.
  {% endtab %}
  {% endtabs %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.platform9.com/private-cloud-director/2026.1/storage/block-storage/volume-backend-configuration-examples/hpe-storage-configurations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
