NGX Storage Knowledge Base
Table of Contents
< All Topics

Configuring OpenStack Cinder FC with NGX Storage Driver

Updated
Print

INFO

To request access to this driver, please submit a support ticket.

This document describes how to install and configure the NGXStorage Cinder FC driver for OpenStack. It covers installation, configuration, and usage of the driver with NGXStorage arrays.

Driver Details

  • Driver module path: cinder.volume.drivers.ngxstorage.fc.NGXStorageFCDriver
  • Driver version: 1.0.0
  • Protocol: Fibre Channel

Requirements

  • OpenStack Cinder services installed (api, scheduler, volume)
  • On compute and volume hosts: FC HBAs connected to SAN fabric (multipath optional)
  • Network access from cinder-volume host(s) to both NGXStorage controllers over HTTPS
  • NGXStorage:
    • API key with sufficient privileges
    • Existing Pool (name or ID)
    • Pre-created FC targets (names) with FC ports assigned
    • SAN fabric zones between OpenStack host WWPNs and NGX Storage FC port WWPNs

Repository layout highlights:

  • src/cinder/volume/drivers/ngxstorage/ — The driver sources
  • scripts/add_openstack.bash — Helper to copy the driver into a system-installed Cinder site-packages and restart services

Install the driver

Optional helper (run on the cinder-volume host):

cd scripts && ./add_openstack.bash

If you prefer manual steps, copy src/cinder/volume/drivers/ngxstorage into the Cinder drivers path that your environment uses (for example /usr/lib/python3/dist-packages/cinder/volume/drivers/ngxstorage) and restart cinder-volume, cinder-scheduler, and cinder-api services.

sudo systemctl restart cinder-volume cinder-scheduler cinder-api

Configure cinder.conf (backend)

Create a backend section and enable it. Key settings required by the driver:

  • ngxstorage_controller_A — Controller A hostname or IP
  • ngxstorage_controller_B — Controller B hostname or IP
  • ngxstorage_api_key — API key for NGXStorage REST
  • ngxstorage_pool_name — Pool name or ID to provision in
  • ngxstorage_fc_target_names — Comma-separated pre-created FC target names

Common/optional settings:

  • volume_backend_name — Logical name used for scheduler routing
  • suppress_requests_ssl_warnings — If true, SSL verification is suppressed
  • use_multipath_for_image_xfer, enforce_multipath_for_image_xfer — Controls os-brick multipath during controller-side image transfers

Minimal backend example

[DEFAULT]
enabled_backends = ngxstorage-fc,...
default_volume_type = ngxstorage-fc

[coordination]
backend_url = file://$state_path

[ngxstorage-fc]
volume_driver = cinder.volume.drivers.ngxstorage.fc.NGXStorageFCDriver
volume_backend_name = NGXStorage-FC-<SERIAL_NUMBER>
ngxstorage_controller_A = 192.168.1.201
ngxstorage_controller_B = 192.168.1.202
ngxstorage_api_key = <YOUR_API_KEY>
ngxstorage_pool_name = <YOUR_POOL_NAME>
ngxstorage_fc_target_names = CinderFCTarget1,CinderFCTarget2

suppress_requests_ssl_warnings = true

Full sample backend (annotated)

[DEFAULT]
enabled_backends = ngxstorage-fc-1

[coordination]
backend_url = file://$state_path

[ngxstorage-fc-1]
# Required
volume_driver = cinder.volume.drivers.ngxstorage.fc.NGXStorageFCDriver
volume_backend_name = NGXStorage-FC-<SERIAL_NUMBER>
ngxstorage_controller_A = 192.168.1.201
ngxstorage_controller_B = 192.168.1.202
ngxstorage_api_key = <YOUR_API_KEY>
ngxstorage_pool_name = <YOUR_POOL_NAME>
ngxstorage_fc_target_names = CinderFCTarget1,CinderFCTarget2

# Optional: controller-side image transfer multipath
use_multipath_for_image_xfer = true
enforce_multipath_for_image_xfer = true

# Suppress ssl warning logs
suppress_requests_ssl_warnings = true

After editing cinder.conf, restart Cinder services:

sudo systemctl restart cinder-volume cinder-scheduler cinder-api

Distributed Locking (Coordination)

For multi-node cinder-volume deployments, configure a shared coordination backend:

[coordination]
backend_url = redis://redis-host:6379

# Multi-node HA — use etcd, redis, zookeeper, etc.:
# backend_url = etcd3://etcd1:2379,etcd2:2379,etcd3:2379
# backend_url = redis://redis-host:6379
# backend_url = zake://zk1:2181,zk2:2181

Single-node deployments work without this section.

Notes:

  • FC targets must be pre-created by the storage administrator via NGX Storage UI
  • SAN fabric zones must be configured between host WWPNs and NGX Storage target WWPNs
  • The driver does NOT create or delete FC targets — they are shared, pre-existing resources

FC and multipath setup for Cinder and Nova hosts

Multipath is automatic for FC — each FC target port provides a separate path. The driver returns all target WWPNs so os-brick discovers LUNs on all paths.

1) Verify FC HBA connectivity

cat /sys/class/fc_host/host*/port_state
cat /sys/class/fc_host/host*/port_name

2) Trigger FC rescan (if LUNs not visible after zoning)

echo "1" | sudo tee /sys/class/fc_host/host*/issue_lip
sleep 2
echo "- - -" | sudo tee /sys/class/scsi_host/host*/scan

3) Install multipath tools

  • Ubuntu / Debian: 
    sudo apt-get install -y multipath-tools
  • RHEL / CentOS: 
    sudo yum install -y device-mapper-multipath

4) Configure multipath for NGX Storage

Recommended /etc/multipath.conf (works for both FC and iSCSI):

defaults {
    polling_interval 5
    user_friendly_names yes
}

devices {
    device {
        vendor "NGX-IO.*"
        product "NGX-IO ISCSI"
        path_grouping_policy group_by_prio
        prio alua
        path_checker tur
        failback immediate
        no_path_retry queue
        flush_on_last_del yes
        dev_loss_tmo infinity
        detect_prio yes
    }
}

Reload multipath:

sudo systemctl reload multipathd

5) Configure Nova for multipath

[libvirt]
volume_use_multipath = True
volume_enforce_multipath = True

Restart Nova compute:

sudo systemctl restart nova-compute

6) Verify multipath

sudo multipath -ll

7) IO scheduler (recommended)

Set the IO scheduler to none for NGX LUNs to reduce CPU overhead:

cat > /etc/udev/rules.d/99-ngxstorage.rules << 'EOF'
ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_VENDOR}=="NGX*", \
  ATTR{queue/scheduler}="none", \
  ATTR{queue/add_random}="0", \
  ATTR{queue/rq_affinity}="2", \
  ATTR{device/timeout}="120"
EOF

sudo udevadm control --reload-rules
sudo udevadm trigger

Image clone/cache

When you create a volume from a Glance image, the driver downloads the image to a cache LUN on the NGX array and takes a snapshot. Subsequent volumes from the same image are fast-cloned from that snapshot — no re-download needed.

The cache is scoped per array and pool. The first create-from-image for a given image seeds the cache; everything after that is a fast clone. No manual bootstrap required.

Create a Volume Type and QoS Spec (vendor properties)

  1. Create a volume type bound to this backend:

    openstack volume type create ngx-fc
openstack volume type set ngx-fc --property volume_backend_name=NGXStorage-FC-<SERIAL>

  2. Create and associate a QoS Spec with NGX vendor keys:

    openstack volume qos create ngx-qos \
  --property NGX:blocksize=auto \
  --property NGX:qos_priority=16 \
  --property NGX:thin_provision=on \
  --property NGX:deduplication=off \
  --property NGX:io_type=auto \
  --property NGX:compression=off \
  --property NGX:dram_cache=on \
  --property NGX:rast=on

QOS_ID=$(openstack volume qos show -f value -c id ngx-qos)
openstack volume type set ngx-fc --qos-spec $QOS_ID

Supported NGX properties (defaults in parentheses):

  • NGX:blocksize (auto): one of 1k, 2k, 4k, 8k, 16k, 32k, 64k, 128k, auto
  • NGX:qos_priority (16): one of 4, 8, 16, 32, 64, 128
  • NGX:thin_provision (on): on|off|auto
  • NGX:deduplication (off): on|off
  • NGX:io_type (auto): sequential|transactional|auto (auto resolves based on pool media)
  • NGX:compression (off): on|off
  • NGX:dram_cache (on): on|off
  • NGX:rast (on): on|off (NGX Real-time Automated Storage Tiering)

Basic usage

  • Create a volume on this backend:

    openstack volume create --type ngx-fc --size 10 demo-vol

  • Attach/detach via normal OpenStack workflows. os-brick FC connector auto-discovers LUNs.

  • Snapshots and clones are supported (create_snapshot, create_volume_from_snapshot).

  • Manage/Unmanage volumes and snapshots are supported.

Troubleshooting

  • Logs: cinder-volume service logs include ngxstorage.fc.* entries:

    journalctl -u cinder-volume -f | grep -i ngxstorage

  • Common init failures:

    • InvalidConfigurationValue: missing required options (controllers, api key, pool, FC target names)
    • No FC targets found: verify targets exist on NGX Storage and match ngxstorage_fc_target_names

  • Connectivity:

    • Verify FC fabric zones include host and storage WWPNs
    • Check cat /sys/class/fc_host/host*/port_state shows “Online”
    • After zoning, trigger FC rescan: echo “1” > /sys/class/fc_host/host*/issue_lip

Capabilities summary

  • Provision/Extend/Delete volumes
  • Snapshots: create/delete, create volume from snapshot, revert to snapshot
  • Image import/export, cloning from images
  • Manage/Unmanage volumes and snapshots
  • FC multipath support (returns all target WWPNs for multi-path discovery)
  • No multiattach (driver advertises multiattach = False)

Support and contributions

Please open issues or PRs for fixes and enhancements. When reporting a problem, include relevant cinder-volume logs (with ngxstorage lines) and your backend stanza (with secrets redacted).