Configure an External NetApp Deployment as the Storage Backend

Configure an external NetApp deployment as the storage backend, after system installation using a StarlingX-provided application netapp-storage.

Prerequisites

StarlingX must be installed and fully deployed before performing this procedure.

Procedure

1. Configure the storage network.

   Follow the next steps to configure storage network

   1. Create an address pool for the storage network if it does not already exist. This step can be completed at any time.

      (keystone_admin)$ system addrpool-add --ranges <start_address>-<end_address> <name_of_address_pool> <network_address> <network_prefix>
      

      For example:

      (keystone_admin)$ system addrpool-add --ranges 10.10.20.1-10.10.20.100 storage-pool 10.10.20.0 24
      

   2. Create the storage network from the designated address pool if it does not already exist.

      For example:

      (keystone_admin)$ system addrpool-list | grep storage-pool | awk '{print$2}' | xargs system network-add storage-net storage true
      

   3. For each host in the system, do the following:

      1. Lock the host.

         (keystone_admin)$ system host-lock <hostname>
         

      2. Create an interface using the address pool.

         For example:

         (keystone_admin)$ system host-if-modify -n storage0 -c platform --ipv4-mode static --ipv4-pool storage-pool controller-0 enp0s9
         

      3. Assign the interface to the network.

         For example:

         (keystone_admin)$ system interface-network-assign controller-0 storage0 storage-net
         

      4. Unlock the host.

         (keystone_admin)$ system host-unlock <hostname>
         

2. Provide NetApp backend configurable parameters in an overrides yaml file.

   You can make changes-in-place to your existing localhost.yml file or create another in an alternative location (~/netapp-overrides.yaml).

   NetApp backend supports NetApp ONTAP NAS (NFS) and NetApp ONTAP SAN (iSCSI and Fibre Channel) configurations. Specify the storage protocol by setting the protocol field in the backends section to nfs, iscsi, or fcp.

   The following examples show minimal configuration options for ONTAP NAS and SAN in netapp-overrides.yaml:

   Note

   This file is organized into the following sections: storageClasses, snapshotClasses, backends, and secret. Multiple backends and storage classes can be defined. The value of backends.credentials.secret_name must match secret.metadata.name. If the secret name is changed, ensure it is updated in both locations.

   1. NetApp ONTAP NAS Configuration (NFS):

      backends:
      - name: "nas-backend"
        protocol: nfs
        managementLIF: "<management IP>"
        dataLIF: "<data IP>"
        svm: "<svm>"
        credentials:
          secret_name: backend-tbc-secret
      
      storageClasses:
      - name: netapp-nas-backend
        parameters:
          backendType: "ontap-nas"
        mountOptions:
          - rw
          - hard
          - intr
          - bg
          - vers=4
          - proto=tcp
          - timeo=600
          - rsize=65536
          - wsize=65536
      
      snapshotClasses:
      - name: csi-snapclass
        deletionPolicy: Delete
      
      secret:
      - metadata:
          name: backend-tbc-secret
        type: Opaque
        stringData:
          username: "<netapp/svm user>"
          password: "<netapp/svm password>"
      

      For more details about the options, see the documentation: https://docs.netapp.com/us-en/trident/trident-use/ontap-nas-examples.html

   2. NetApp ONTAP SAN Configuration (iSCSI / FC):

      Note

      If an iSCSI backend is configured, the find_multipaths setting in /etc/multipath.conf will be automatically changed to no.

      backends:
      - name: "san-backend"
        protocol: <iscsi or fcp>
        managementLIF: "<management IP>"
        svm: "<svm>"
        credentials:
          secret_name: backend-tbc-secret
      
      storageClasses:
      - name: netapp-san-backend
        parameters:
          backendType: "ontap-san"
      
      snapshotClasses:
      - name: csi-snapclass
        deletionPolicy: Delete
      
      secret:
      - metadata:
          name: backend-tbc-secret
        type: Opaque
        stringData:
          username: "<netapp/svm user>"
          password: "<netapp/svm password>"
      

   3. Set the backend configuration provided in your yaml file by updating the application Helm overrides:

      (keystone_admin)$ system helm-override-update netapp-storage netapp-trident-provisioner trident --values netapp-overrides.yaml
      

3. Apply the application:

   (keystone_admin)$ system application-apply netapp-storage
   

   Wait for the netapp-storage application to show status applied:

   (keystone_admin)$ system application-show netapp-storage
   +---------------+----------------------------------+
   | Property      | Value                            |
   +---------------+----------------------------------+
   | active        | True                             |
   | app_version   | 1.0-1                            |
   | created_at    | 2026-06-15T10:30:00.000000+00:00 |
   | manifest_file | fluxcd-manifests                 |
   | manifest_name | netapp-storage-fluxcd-manifests  |
   | name          | netapp-storage                   |
   | progress      | completed                        |
   | status        | applied                          |
   +---------------+----------------------------------+
   

4. Confirm that the pods launched successfully.

   Once application is applied, there will be one Trident pod running on each node, plus an extra pod for the REST API running on one of the controller nodes.

   In an all-in-one simplex environment you will see pods similar to the following:

   (keystone_admin)$ kubectl -n trident get pods
   NAME                                  READY   STATUS    RESTARTS   AGE
   trident-controller-657cfd989d-gfq4q   5/5     Running   0          0h2m
   trident-node-linux-cqq69              2/2     Running   0          0h2m
   trident-operator-774b6c5568-xcvtg     1/1     Running   0          0h2m
   

5. Checking configured TBCs.

   To view the configured TBCs, run the following command:

   (keystone_admin)$ kubectl -n trident get tbc
   NAME        BACKEND NAME   BACKEND UUID                           PHASE   STATUS
   ontap-nas   ontap-nas      2fbc80cd-6933-4efc-84c6-0550ac99309d   Bound   Success
   

   This will list the TBCs in the trident namespace, allowing you to check the status and configuration of storage volume provisioning. The PHASE must be Bound and STATUS must be Success. If not, check your backend configuration.

Postrequisites

To configure a persistent volume claim for the NetApp backend, add the appropriate storage class name you set up (netapp-nas-backend or netapp-san-backend) to the persistent volume claim’s yaml configuration file. For more information about this file, see StarlingX User Tasks: Create ReadWriteOnce Persistent Volume Claims.

Configure NetApps Using a Private Docker Registry

Use the docker_registries parameter to pull from the local registry rather than public ones.

You must first push the files to the local registry.