OpenNebula Datastore on FlashArray Quick Start Guide

• Full lifecycle control. Create, clone, resize, rename, and delete FlashArray volumes directly from OpenNebula, without manual array-side operations.

• Instant, thin snapshots and clones. Everpure's metadata-only snapshots enable immediate, zero-copy cloning for both persistent and non-persistent VMs, minimizing capacity overhead.

• Latency-stable I/O path. FlashArray keeps read/write latency flat even with long snapshot chains. Multipath iSCSI is configured automatically per Host for resilient connectivity.

• Synchronous REST orchestration. Operations use the FlashArray's synchronous REST API with explicit error handling and safe sequencing for volume, snapshot, and host mapping tasks.

• Incremental SAN-snapshot backups. Block-level incremental backups are driven by comparing FlashArray snapshot pairs via raw device attachment—no in-guest backup agents are required.

• HTTPS control path. All FlashArray communication uses authenticated, encrypted HTTPS REST calls.

• Simplified Host-group mappings. Host and Host-group mappings use deterministic LUN IDs and predictable multipath layouts, enabling safe, concurrent attach/detach operations across Hosts.

• Zero-Copy Volume Clone. Everpure clones are metadata-only and complete instantly.

• Snapshot (manual). Created and deleted directly from OpenNebula; mapped 1:1 to FlashArray snapshots.

• Snapshot restore. Volume overwrite-from-snapshot supported via the REST API.

• Incremental backups (SAN snapshot diff). Utilizes FlashArray Volume Diff API to gather block differences, then copies the data.

• Host management. Hosts are automatically created and mapped to as needed.

• Multi-path I/O. Fully orchestrated; automatic detection, resize, and removal of maps.

• Data encryption (at-rest). Supported transparently by the array (always-on AES-XTS); not managed by OpenNebula.

• Snapshot retention/policies. FlashArray snapshot schedules are available on the array, but OpenNebula does not manage array-side policies. Snapshots created via this integration remain under OpenNebula's control.

• QoS policy groups. Not currently exposed through the datastore driver.

• SVM DR / MetroCluster. Supported by FlashArray, but not orchestrated by OpenNebula.

• Protection Groups / ActiveCluster. Planned for future releases; can be managed externally on the FlashArray.

• Bandwidth / IOPS limits. FlashArray supports QoS, but these controls are not integrated into the datastore driver.

• Deduplication & compression metrics. Calculated internally by FlashArray; not displayed or consumed by OpenNebula.

• Per-volume encryption toggling. FlashArray encryption is always-on and appliance-managed; no OpenNebula API exposure.

1. Verify iSCSI Service Connections

   • On the FlashArray GUI, go to Settings > Network > Connectors.

   • Ensure the iSCSI connectors are enabled and note their IP addresses.

2. Create an API User

   • In the FlashArray System Manager, go to Settings > Access > Users.

   • Create a new user with the Storage Admin role. This role should provide enough permissions for OpenNebula.

   • Create an API token for this user and note the API key. Leave the expiration date blank to create an indefinite API key.

1. API Access. Ensure network connectivity to the Everpure FlashArray API interface. The datastore will be in an ERROR state if the API is not accessible or cannot be monitored properly.

1. iSCSI: Discover the iSCSI targets on the Hosts using the following command:

   iscsiadm -m discovery -t sendtargets -p <target_ip>   # for each iSCSI target IP from the FlashArray

2. Persistent iSCSI Configuration:

   • Set node.startup = automatic in /etc/iscsi/iscsid.conf.

   • Ensure iscsid is started with systemctl status iscsid.

   • Enable iscsid with systemctl enable iscsid.

3. Multi-path Configuration: Update /etc/multipath.conf to something like:

   defaults {
            polling_interval       10
    }
   
   
    devices {
        device {
            vendor                      "NVME"
            product                     "Pure Storage FlashArray"
            path_selector               "queue-length 0"
            path_grouping_policy        group_by_prio
            prio                        ana
            failback                    immediate
            fast_io_fail_tmo            10
            user_friendly_names         no
            no_path_retry               0
            features                    0
            dev_loss_tmo                60
        }
        device {
            vendor                   "PURE"
            product                  "FlashArray"
            path_selector            "service-time 0"
            hardware_handler         "1 alua"
            path_grouping_policy     group_by_prio
            prio                     alua
            failback                 immediate
            path_checker             tur
            fast_io_fail_tmo         10
            user_friendly_names      no
            no_path_retry            0
            features                 0
            dev_loss_tmo             600
        }
    }
   

$ cat purefa_system.ds

NAME              = "purefa_system"
TYPE              = "SYSTEM_DS"
DISK_TYPE         = "BLOCK"
TM_MAD            = "purefa"
PUREFA_HOST       = "10.1.234.56"
PUREFA_API_TOKEN  = "01234567-89ab-cdef-0123-456789abcdef"
PUREFA_TARGET     = "iqn.1993-08.org.ubuntu:01:1234"

$ onedatastore create purefa_system.ds

ID: 101

$ cat purefa_image.ds

NAME              = "purefa_image"
TYPE              = "IMAGE_DS"
DISK_TYPE         = "BLOCK"
DS_MAD            = "purefa"
TM_MAD            = "purefa"
PUREFA_HOST       = "10.1.234.56"
PUREFA_API_TOKEN  = "01234567-89ab-cdef-0123-456789abcdef"
PUREFA_TARGET     = "iqn.1993-08.org.ubuntu:01:1234"

$ onedatastore create purefa_image.ds

ID: 102

• Images: Stored as a single Volume in Everpure FlashArray

• Naming Convention:

  • Image datastore: one_<datastore_id>_<image_id>

  • System datastore: one_<vm_id>_disk_<disk_id>

• Operations:

  • Non‐persistent: Clone

  • Persistent: Rename

• Full Backups: A snapshot of the Volume containing the VM disk is taken and attached to the Host, where it is converted into a QCOW2 image and uploaded to the backup datastore.

• Incremental Backups: Created using the Volume Difference feature of the FlashArray. This returns a list of block offsets and lengths which have changed since a target snapshot. This list is then used to create a sparse QCOW2 format file which is uploaded to the backup datastore.

• If you have extra devices from failures leftover, run:

  rescan_scsi_bus.sh -r -m

• If an entire multipath setup remains, run:

  multipath -f <multipath_device>

  Note: Be very careful to target the correct multipath device.

1. Run dmsetup ls --tree or lsblk to see which mapped devices remain. You may see devices not attached to a mapper entry in lsblk.

2. For each such device (not your root device), run:

   echo 1 > /sys/bus/scsi/devices/sdX/device/delete

   where sdX is the device name.

3. Once those devices are gone, remove leftover mapper entries:

   dmsetup remove /dev/mapper/<device_name>

4. If removal fails:

   • Check usage:

     fuser -v $(realpath /dev/mapper/<device_name>)

   • If it's being used as swap:

     swapoff /dev/mapper/<device_name>
     dmsetup remove /dev/mapper/<device_name>

   • If another process holds it, kill the process and retry:

     dmsetup remove /dev/mapper/<device_name>

   • If you can't kill the process or nothing shows up:

     dmsetup suspend /dev/mapper/<device_name>
     dmsetup wipe_table /dev/mapper/<device_name>
     dmsetup resume /dev/mapper/<device_name>
     dmsetup remove /dev/mapper/<device_name>