# Manage external storage

> This guide covers how to utilize external storage in CubeCOS, including attaching volumes, verifying connections, and troubleshooting multipath storage across FC, iSCSI, and NFS.

This guide provides instructions on how to configure and manage external storage within the CubeCOS system.

## Key terminology {#key-terminology}

Before starting, please familiarize yourself with the following technical terms used in this guide:

- **Model**: A storage template that defines the required settings and parameter specifications for a specific external storage type.
- **Vendor Driver**: The software bridge that allows CubeCOS to communicate with specific hardware from vendors like Dell EMC or Fujitsu.
- **Multipath**: A fault-tolerance mechanism that allows a server to access storage through multiple physical paths to ensure constant connectivity.

## Manage Storage Models {#manage-storage-models}

Models act as the primary configuration guide for your storage setup.

### How to import a new model {#how-to-import-a-new-model}

1. Navigate to **Home** > **Integrations** > **Storages** > **Model list**.

2. To define the driver, write a YAML file and click "Import a new model" and upload the YAML file.

3. Once the format is validated, a success toast will pop up, and the new model will appear in the model list.

:::info

The 5 built-in templates are permanent, deleting them only resets any customized override values.

:::

### YAML Configuration & Parameter Definitions {#yaml-configuration--parameter-definitions}

Below is an example of a Dell EMC SC FC template with inline comments explaining the parameters:

```yaml
# The specific Cinder driver class for the hardware vendor
driver: 'cinder.volume.drivers.dell_emc.sc.storagecenter_fc.SCFCDriver'
vendor: 'Test'
type: 'SC Series FC'

# Multipath Configuration: Defines how the system handles redundant paths
multipath:
  - section: 'devices'
    attributes: []
    subSections:
      storage:
        section: 'device'
        attributes:
          service:
            - key: 'vendor'
              value: 'COMPELNT' # Internal identifier for the storage hardware
            - key: 'product'
              value: 'Compellent Vol' # Specifies the volume product type
            - key: 'user_friendly_names'
              value: 'no' # Prevents renaming of paths for system consistency

# Driver-specific settings for network and performance
driverSection:
  - key: 'san_ip' # The Management IP address of the SAN hardware
    value: ''
  - key: 'san_login' # Administrative username for storage access
    value: ''
  - key: 'use_multipath_for_image_xfer'
    value: 'true' # Enables path redundancy specifically for moving VM images
  - key: 'image_upload_use_cinder_backend'
    value: 'true' # Directs image uploads through the Cinder driver for efficiency
```

## Troubleshooting {#troubleshooting}

If any errors occur while connecting or managing external storage, follow these diagnostic methods to find the root cause.

### Notifications {#notifications}

This serves as the system's alert dashboard. Since CubeCOS operations are cluster-wise, a configuration may apply successfully to one node while failing on another. The notification center identifies exactly which nodes are out of sync or have encountered a **Failure** during the update process. Please refer to the following methods see these notifications:

Navigate to **Home** > **Notifications**.(The bell icon is at the upper-right corner)

  

### Logs {#logs}

While notifications report that a failure happened, the logs explain the failure. This is the most granular way to see the communication between the CubeCOS API and the storage hardware. To detect the logs, please follow the steps below:

1. Log in to the failure node.

   ```bash=
   ssh <user_name>@<your-node-ip>
   ```

> **Command Variables:**
>
> - `<user_name>`: This is the username of the failure node.
> - `<your_node-ip>`: This is the IP address of the failure node.

2. Check the logs by running the following command:

   ```bash=
   $ journalctl -f -u cube-cos-api
   ```

3. Find the following keywords in the logs:
   - **hex_config**: Points to issues with the internal configuration engine.
   - **cinder**: Indicates the OpenStack block storage service is having trouble mounting or recognizing the volume.
   - **storage / model**: Suggests the parameters in your template (like the SAN IP or credentials) are incorrect or rejected by the vendor driver.

### Recommended Resolution {#recommended-resolution}

For most integration failures, the most effective recovery method is to re-perform the corresponding UI operation. Because the UI triggers a cluster-wise operation, this forces every node to re-attempt the configuration simultaneously. This ensures that all nodes maintain a consistent configuration status and return to a synchronized, functional state.