# Configure external storage integrations

> Configure external SAN and NAS storage integration in CubeCOS to host VM disks and images, optimize internal SDS usage, and support hybrid storage architectures.

## External storage configuration overview {#external-storage-configuration-overview}

This guide explains how to connect your external storage systems (SAN or NAS) to CubeCOS.

Adding a new storage system to CubeCOS involves three stages: registering the backend, providing connection details, and verifying the configuration.

1. **Enable the Backend:**: Register the new storage system with CubeCOS before configuring any connection parameters.
2. **Add Connection Details:**: Add connection details. Provide the specific IP address and login credentials for your storage type (FC, iSCSI, or NFS).
3. **Apply & Verify:**: Apply and verify by restarting the services to finalize the connection.

## Add external storage {#add-external-storage}

After setting up a template, link the physical hardware to the system.

1. Navigate to **Home** > **Integrations** > **Storages** > **Add external storage** and select the model you want to use.

   
   
   

2. Fill in the fields corresponding to your storage configuration.

   
   
   

   :::info[**Required Fields**]
   - **Storage Name**: A custom name for this storage.
   - **Vendor**: Select the template you imported (e.g., Dell EMC SC FC).
   - **Credentials**: Enter the SAN management IP, login, and password as defined by your driver.

   :::

3. Wait for the system update and Click **Verify** make sure the driver and values you filled can works properly.

   
   
   

4. Once verification succeeds, the storage entry will show as **Verified** in the list.

   
   
   

   :::warning

   Non-verified storage can still be selected in CubeCOS, but proper functionality is not guaranteed.

   :::

<!--
## Step 1: Enable the Backend (Common Setup) {#step-1-enable-the-backend-common-setup}

First, you need to define a unique name for your new storage and add it to the global configuration.

1.  Open the configuration file on your Control Node:
    `/etc/cinder/cinder.conf`

2.  Locate the `[DEFAULT]` section and find the `enabled_backends` and `default_volume_type` lines.

3.  Append your new Storage Name to the `enabled_backends` list and define your Storage Type.

    ```ini
    [DEFAULT]
    default_volume_type = <storage_type>
    enabled_backends = ceph,<storage_name>
    allowed_direct_url_schemes = cinder
    glance_request_timeout = 1200
    ```

> **Configuration Variables:**
>
> - \<storage_name>: This backend ID must exactly match the section header in Step 2.
> - \<storage_type>: This is a logical label you create manually. For the setup and mapping commands, refer to the [volume management section](utilization#manage-volume).

## Step 2: Cinder (Block Storage) {#step-2-cinder-block-storage}

**Purpose:** Cinder provisions and manages block storage volumes. When a user creates a virtual machine and attaches a "hard drive" to it, Cinder is the service communicating with your external SAN or NAS to create and map that raw volume.

Choose the configuration below that matches your storage protocol. Add these details to the bottom of `/etc/cinder/cinder.conf` (or create a new file in `/etc/cinder/cinder.d/`).

### Option A: FC SAN (Fibre Channel) {#option-a-fc-san-fibre-channel}

Use this for storage arrays connected via Fibre Channel (e.g., Dell SC Series).

    ```ini
    [MyExternalStorage]
    # Must match the name from Step 1
    volume_backend_name = MyExternalStorage

    # The specific driver for your hardware (Check vendor docs for the exact string)
    # Example below is for Dell Storage Center
    volume_driver = cinder.volume.drivers.dell.dell_storagecenter_fc.DellStorageCenterFCDriver

    # Connection Info
    san_ip = <STORAGE_MANAGEMENT_IP>
    san_login = <ADMIN_USERNAME>
    san_password = <ADMIN_PASSWORD>
    ssn = <STORAGE_SERIAL_NUMBER>
    api_port = 3033
    ```

### Option B: iSCSI SAN {#option-b-iscsi-san}

Use this for arrays connected via Ethernet using iSCSI (e.g., NetApp or Generic iSCSI).

    ```ini
    [MyExternalStorage]
    volume_backend_name = MyExternalStorage
    volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver

    # Connection Info
    netapp_server_hostname = <STORAGE_DATA_IP>
    netapp_login = <ADMIN_USERNAME>
    netapp_password = <ADMIN_PASSWORD>
    netapp_storage_protocol = iscsi
    ```

### Option C: NFS External (Supported Vendor) {#option-c-nfs-external-supported-vendor}

Use this for NAS devices with advanced driver support (e.g., NetApp NFS).

1. Add the configuration:

   ```ini
   [MyExternalStorage]
   volume_backend_name = MyExternalStorage
   volume_driver = cinder.volume.drivers.netapp.common.NetAppDriver
   netapp_server_hostname = <STORAGE_IP>
   netapp_login = <ADMIN_USERNAME>
   netapp_password = <ADMIN_PASSWORD>
   netapp_storage_protocol = nfs
   nfs_shares_config = /etc/cinder/nfs_shares_netapp
   ```

2. Create the shares file: Create `/etc/cinder/nfs_shares_netapp` and add your export path:

   ```Plaintest
   <STORAGE_IP>:/<EXPORT_PATH>
   ```

### Option D: Generic NFS {#option-d-generic-nfs}

Use this for standard Linux NFS servers or simple NAS devices.

1. Add the configuration:

   ```ini
   [MyExternalStorage]
   volume_backend_name = MyExternalStorage
   volume_driver = cinder.volume.drivers.nfs.NfsDriver
   nfs_shares_config = /etc/cinder/nfs_shares
   nfs_mount_options = v3,lookupcache=pos
   ```

2. Create the shares file: Create `/etc/cinder/nfs_shares` and add your export path:

   ```Plaintest
   <NFS_SERVER_IP>:/var/nfs/cinder-volumes
   ```

## Step 3: Manila (Shared File Systems) {#step-3-manila-shared-file-systems}

**Purpose:** Manila provisions coordinated, shared file systems (like NFS or CIFS). Unlike Cinder volumes which are typically attached to a single instance, Manila shares can be mounted by multiple virtual machines simultaneously, making it ideal for clustered applications or shared data repositories.

Modify your Manila configuration file (typically /etc/manila/manila.conf) to enable the generic driver and define the share protocols.

```ini
[DEFAULT]
default_share_type = tenant_share_type
enabled_share_backends = generic
enabled_share_protocols = NFS,CIFS

[generic]
cinder_volume_type = DellFC
connect_share_server_to_tenant_network = true
driver_handles_share_servers = true
interface_driver = manila.network.linux.interface.OVSInterfaceDriver
share_backend_name = GENERIC
share_driver = manila.share.drivers.generic.GenericShareDriver
```

## Step 4: Glance (Image Storage) {#step-4-glance-image-storage}

**Purpose:** Glance acts as the registry and repository for virtual machine images. By configuring Glance to use your external Cinder storage as a backend, you can significantly speed up instance creation times using volume-backed images (boot-from-volume).

Modify the Glance API configuration file (typically `/etc/glance/glance-api.conf`) to point to your new Cinder backend.

```bash
[DEFAULT]
show_image_direct_url = true
show_multiple_locations = true
enabled_backends = http:http,cube:rbd,<storage_name>:cinder,...

[cinder]
cinder_use_multipath = true
cinder_enforce_multipath = true
cinder_state_transition_timeout = 1200

[<storage_name>]
store_description = "<storage_name>"
cinder_store_auth_address = http://<vip>:5000
cinder_store_user_name = glance
cinder_store_password = <glance_password>
cinder_store_project_name = service
cinder_volume_type = "<storage_name>"

[glance_store]
default_backend = <storage_name>
```

> **Configuration Variables:**
>
> - \<vip>: The Virtual IP of your load balancer (or the Controller node's IP in non-HA setups) used to reach the Keystone authentication service.

## Step 5: Apply & Verify (Finalize) {#step-5-apply--verify-finalize}

Once the configuration is saved, restart the service to establish the connection.

1. Restart the Service

   ```bash
   systemctl restart openstack-cinder-volume
   ```

2. Verify the Connection Check if the service is "UP" and your new storage pool is listed.

   ```bash
   # Check service status
   openstack volume service list

   # Check if the new pool is available
   openstack volume backend pool list
   ```

3. (Optional) Create a Test Volume

   ```bash
   openstack volume create --size 1 --type <storage_name> test_vol_01
   ```
-->

## Troubleshooting external storage issues {#troubleshooting-external-storage-issues}

If your backend does not appear as active or you cannot attach volumes, use the following commands to diagnose the issue at each layer.

1. Verify disk multipath management

   Multipath is required by external SANs to handle redundant links.
   - Verify path status: Ensure that you see multiple paths to your storage LUNs.
   - Check daemon status: Ensure the multipath service is active and running.

     ```bash
     systemctl status multipathd
     ```

   - Test your configuration: Validate your configuration file for syntax errors before applying it.

     ```bash
     # This shows the compiled configuration and checks for errors
     multipath -t
     ```

   - Check custom configs: Verify if any vendor-specific configuration files exist in the subdirectory.

     ```bash
     ls -ahl /etc/multipath/conf.d
     ```

   - Reload configs: If you changed `/etc/multipath.conf`, reload without rebooting.

     ```bash
     # 1. Reload the service: Tells the daemon to re-read the configuration file.
     systemctl reload multipathd

     # 2. Reload device maps: Forces the kernel to update the actual path mappings.
     multipath -r
     ```

   - Verify Path Status: Ensure you see multiple paths to your storage LUNs.

     ```bash
     multipath -ll
     ```

2. Check the volume and device mapping
   - Check if the system has mapped the external storage to local device nodes.

     ```bash
     # List all mapped devices
     ls -ahl /dev/mapper
     ```

   - Display a tree view of all available block devices.

     ```bash
     lsblk
     ```

   - Show details for a specific mapped volume (e.g., replace `your_device_name` with `sda1` or `vg0-lv1`).

     ```bash
     lsblk -ln /dev/mapper/your_device_name
     ```

   - Show custom columns, such as file system and transport type.

     ```bash
     lsblk -ln -o NAME,KNAME,TYPE,TRAN,RO,PARTLABEL,LABEL,FSTYPE,SIZE,MOUNTPOINT
     ```

3. Check the service status and logs

   If the services appear "down" or the backend pools are missing, verify the status of the following core components on your controller/storage nodes:
   - Check Cinder status

     Ensure that the management API, scheduler, and volume drivers are active:

     ```bash
     systemctl status openstack-cinder-api openstack-cinder-scheduler openstack-cinder-volume
     # Optional: Only if using backup features
     systemctl status openstack-cinder-backup
     ```

   - Glance (Image Storage)

     If image-backed volumes fail or Step 4 was applied, verify the Glance API:

     ```bash
     systemctl status openstack-glance-api
     ```

   - Manila (Shared File Systems)

     Ensure that the share management services and drivers are running.

     ```bash
     systemctl status openstack-manila-api openstack-manila-scheduler openstack-manila-share
     ```