Deploying NetApp ONTAP Manila Driver in Red Hat OpenStack Services on OpenShift 18.0

updated: 2026-04-23 11:35

Deploying NetApp ONTAP Manila Driver in Red Hat OpenStack Services on OpenShift 18.0

Deploying NetApp ONTAP Manila Driver in Red Hat OpenStack Services on OpenShift 18.0¶

Overview¶

This guide describes how to configure and deploy the NetApp ONTAP Manila driver in a Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 control plane. After completing this guide, you will be able to define the required environment files and deploy single or multiple ONTAP Manila backends in the RHOSO control plane.

Note

For more information about RHOSO, see the documentation pages.

Warning

RHOSO 18.0 is based on the OpenStack Antelope release. Features introduced after Antelope are not available in RHOSO 18.0.

Requirements¶

To deploy NetApp Manila backends, ensure the following requirements are met:

NetApp ONTAP storage controllers deployed and ready for use as Manila backends. See ONTAP Prerequisites for details.
RHOSO control plane deployed on an OpenShift cluster with three master nodes and three worker nodes.
RHOSO control plane where Manila services will be installed.
Ensure network connectivity between the storage backend, the Red Hat OpenShift cluster, and the Compute nodes.

Deployment Steps¶

Prepare the OpenStack Control Plane CR¶

Install the Red Hat OpenStack Services on OpenShift (RHOSO) OpenStack Operator (openstack-operator) and create the RHOSO control plane on an operational Red Hat OpenShift Container Platform (RHOCP) cluster. Install the OpenStack Operator using the RHOCP web console.

Single Backend Configuration¶

To configure a single NetApp Manila backend, open your OpenStackControlPlane CR file and add the following parameters to the Manila template.

openstack_control_plane.yaml

  spec:
      ...
      manila:
        enabled: true
        template:
          manilaAPI:
            ...
          manilaScheduler:
            ...
          manilaShares:
            share1:
              networkAttachments:
              - storage
              customServiceConfigSecrets:
              - manila_netapp_secret
              customServiceConfig: |
              [DEFAULT]
              debug = true
              enabled_share_backends=netapp-ontap-backend
              [netapp-ontap-backend]
              driver_handles_share_servers=False
              share_backend_name=netapp-ontap-backend
              share_driver=manila.share.drivers.netapp.common.NetAppDriver
              netapp_storage_family=ontap_cluster
              netapp_volume_name_template ='share_%(share_id)s'
              netapp_vserver = 'vserver_name'
              #Use below aggregate param in case of DHSS=True and remove above vserver param.
              #netapp_root_volume_aggregate = 'aggr0'
              replication_domain = netapp_replication_domain
              default_share_type = dhss_false
              backend_availability_zone=manila-zone-1
              #Use below configuration options for enabling "Standalone Network Plugin" with DHSS=True
              #network_api_class = manila.network.standalone_network_plugin.StandaloneNetworkPlugin
              #standalone_network_plugin_allowed_ip_ranges = *.*.*.*-*.*.*.*
              #standalone_network_plugin_gateway = *.*.*.*
              #standalone_network_plugin_mask = 255.255.255.0
              #standalone_network_plugin_ip_version = 4
              #standalone_network_plugin_network_type = flat
      ...

Modify the parameter values to match your NetApp ONTAP backend configuration. Run the following command to apply the changes:

oc apply -f openstack_control_plane.yaml -n openstack

Note

For information on the Standalone Network Plug-in, see: https://netapp-openstack-dev.github.io/openstack-docs/antelope/manila/configuration/manila_config_files/network_plugins/section_standalone_network_plugin.html#standalone-network-plugin

Note

The section covering the secret associated with customServiceConfigSecrets should precede applying the new control plane. The secret must be created before it is referenced in the control plane CRD.

Note

Create a server connection secret for an alternative backend to avoid placing server connection information directly in the OpenStackControlPlane CR.

The following is an example of the contents of a configuration file:

[netapp-ontap-backend]
netapp_server_hostname = <netapp_ip>
netapp_login = <netapp_user>
netapp_password = <netapp_password>
netapp_vserver = <netappvserver>

Create the secret based on the configuration file: oc create secret generic <secret_name> –from-file=secret-config.conf -n openstack

For a complete list of available Manila configuration options, see: - NetApp Unified Driver for ONTAP with Share Server management (Antelope): https://netapp-openstack-dev.github.io/openstack-docs/antelope/manila/configuration/manila_config_files/section_unified-driver-with-share-server.html - NetApp Unified Driver for ONTAP without Share Server management (Antelope): https://netapp-openstack-dev.github.io/openstack-docs/antelope/manila/configuration/manila_config_files/section_unified-driver-without-share-server.html

If you are migrating from RHOSP-17.1, the following table maps each THT configuration parameter to the corresponding Manila configuration option. The Manila template in the OpenStackControlPlane CR uses only the Manila configuration option parameters.

THT Parameter Name	Manila Configuration Option	Required/Optional	Description
`ManilaNetappBackendName`	`share_backend_name`	Required	The name used by Manila to refer to the Manila backend.
`ManilaNetappLogin`	`netapp_login`	Required	Administrative user account name used to access the storage system.
`ManilaNetappDriverHandlesShareServers`	`driver_handles_share_servers`	Required	Denotes whether the driver should handle the responsibility of managing share servers. This must be set to `true` if the driver is to manage share servers.
`ManilaNetappPassword`	`netapp_password`	Required	Password for the administrative user account specified in the `netapp_login` option.
`ManilaNetappServerHostname`	`netapp_server_hostname`	Required	The hostname or IP address for the storage system or proxy server. The value of this option should be the IP address of the cluster management LIF.
`ManilaNetappTransportType`	`netapp_transport_type`	Required	Transport protocol for communicating with the storage system or proxy server. Valid options include `http` and `https`.
`ManilaNetappStorageFamily`	`netapp_storage_family`	Required	The storage family type used on the storage system; valid values are `ontap_cluster` for ONTAP.
`ManilaNetappServerPort`	`netapp_server_port`	Optional	The TCP port to use for communication with the storage system or proxy server. If not specified, ONTAP drivers will use 80 for HTTP and 443 for HTTPS.
`ManilaNetappVolumeNameTemplate`	`netapp_volume_name_template`	Optional	This option specifies a string replacement template that is applied when naming FlexVol volumes that are created as a result of provisioning requests.
`ManilaNetappVserver`	`netapp_vserver`	Required	This option specifies the storage virtual machine (previously called a Vserver) name on the storage cluster on which provisioning of shared file systems should occur. This parameter is required if the driver is to operate without managing share servers (that is, be limited to the scope of a single SVM).
`ManilaNetappVserverNameTemplate`	`netapp_vserver_name_template`	Optional	This option specifies a string replacement template that is applied when naming FlexVol volumes that are created as a result of provisioning requests.
`ManilaNetappLifNameTemplate`	`netapp_lif_name_template`	Optional	This option specifies a string replacement template that is applied when naming data LIFs that are created as a result of provisioning requests.
`ManilaNetappAggrNameSearchPattern`	`netapp_aggregate_name_search_pattern`	Optional	This option specifies a regular expression that is applied against all available aggregates. This filtered list will be reported to the Manila scheduler as valid pools for provisioning new shares.
`ManilaNetappRootVolumeAggr`	`netapp_root_volume_aggregate`	Optional	This option specifies name of the aggregate upon which the root volume should be placed when a new SVM is created to correspond to a Manila share server.
`ManilaNetappRootVolume`	`netapp_root_volume`	Optional	This option specifies name of the root volume that will be created when a new SVM is created to correspond to a Manila share server.
`ManilaNetappPortNameSearchPattern`	`netapp_port_name_search_pattern`	Optional	This option allows you to specify a regular expression for overriding the selection of network ports on which to create Vserver LIFs.
`ManilaNetappTraceFlags`	`netapp_trace_flags`	Optional	This option is a comma-separated list of options (valid values include `method` and `api`) that controls which trace info is written to the Manila logs when the debug level is set to `True`.
`ManilaNetappEnabledShareProtocols`	`netapp_enabled_share_protocols`	Optional	This option specifies the NFS protocol versions that will be enabled on new SVMs created by the driver. Valid values include nfs3, nfs4.0, nfs4.1.
`ManilaNetappVolumeSnapshotReservePercent`	`netapp_volume_snapshot_reserve_percent`	Optional	This option specifies the percentage of share space set aside as reserve for snapshot usage. Valid values range from 0 to 90.
`ManilaNetappSnapmirrorQuiesceTimeout`	`netapp_snapmirror_quiesce_timeout`	Optional	The maximum time in seconds to wait for existing snapmirror transfers to complete before aborting when promoting a replica.
`ManilaNetappVolumeSnapshotReservePercent`	`netapp_volume_snapshot_reserve_percent`	Optional	The percentage of share space set aside as reserve for snapshot usage; valid values range from 0 to 90.

Table 7.1. Manila NetApp Configuration Parameters

Multiple backend configuration¶

To configure multiple NetApp Manila backends, define all backends in the OpenStackControlPlane CR.

Open your OpenStackControlPlane CR file (openstack_control_plane.yaml) and add the following parameters to the Manila template to configure multiple backends. The following example shows how to add multiple NetApp Manila backends.

netapp-multi-backend.yaml

This file defines the multiple Manila share backend netapp-multi-backend.yaml and its parameters.

  spec:
      ...
      manila:
        enabled: true
        template:
          manilaAPI:
            ...
          manilaScheduler:
            ...
          manilaShares:
            share1:
              networkAttachments:
              - storage
              customServiceConfigSecrets:
              - manila_netapp_secret
              customServiceConfig: |
              [DEFAULT]
              debug = true
              enabled_share_backends=netapp-ontap-primary-backend
              [netapp-ontap-primary-backend]
              driver_handles_share_servers=False
              share_backend_name=netapp-ontap-primary-backend
              share_driver=manila.share.drivers.netapp.common.NetAppDriver
              netapp_storage_family=ontap_cluster
              netapp_volume_name_template='share_%(share_id)s'
              netapp_vserver='vserver_name_primary'
              #Use below aggregate param in case of DHSS=True and remove above vserver param.
              #netapp_root_volume_aggregate = 'aggr0'
              replication_domain = netapp_replication_domain
              backend_availability_zone=manila-zone-1
              #Use below configuration options for enabling "Standalone Network Plugin" with DHSS=True
              #network_api_class = manila.network.standalone_network_plugin.StandaloneNetworkPlugin
              #standalone_network_plugin_allowed_ip_ranges = *.*.*.*-*.*.*.*
              #standalone_network_plugin_gateway = *.*.*.*
              #standalone_network_plugin_mask = 255.255.255.0
              #standalone_network_plugin_ip_version = 4
              #standalone_network_plugin_network_type = flat
            share2:
              networkAttachments:
              - storage
              customServiceConfigSecrets:
              - manila_netapp_secret_sec
              customServiceConfig: |
              [DEFAULT]
              debug = true
              enabled_share_backends=netapp-ontap-secondary-backend
              [netapp-ontap-secondary-backend]
              driver_handles_share_servers=False
              share_backend_name=netapp-ontap-secondary-backend
              share_driver=manila.share.drivers.netapp.common.NetAppDriver
              netapp_storage_family=ontap_cluster
              netapp_volume_name_template='share_%(share_id)s'
              netapp_vserver='vserver_name_sec'
              #Use below aggregate param in case of DHSS=True and remove above vserver param.
              #netapp_root_volume_aggregate='aggr0'
              replication_domain = netapp_replication_domain
              backend_availability_zone=manila-zone-2
              #Use below configuration options for enabling "Standalone Network Plugin" with DHSS=True
              #network_api_class = manila.network.stand-alone_network_plugin.StandaloneNetworkPlugin
              #standalone_network_plugin_allowed_ip_ranges = *.*.*.*-*.*.*.*
              #standalone_network_plugin_gateway = *.*.*.*
              #standalone_network_plugin_mask = 255.255.255.0
              #standalone_network_plugin_ip_version = 4
              #standalone_network_plugin_network_type = flat
      ...

Modify the parameter values to match your NetApp ONTAP backend configuration.

Run the following command to apply the changes or edit the OpenStackControlPlane CR file:

oc apply -f openstack_control_plane.yaml -n openstack

Wait until RHOSO creates the Manila share pod. Run the following command to check the status:

oc get openstackcontrolplane -n openstack

Note

[Applicable only for DHSS=False] Starting with ONTAP 9.13.1, there is a design change for deleting flexclone volumes. ONTAP 9.13.1 introduces a volume retention option by default. This means that flexclone volumes (equivalent to “shares created from snapshot” in OpenStack) deleted in OpenStack are retained in ONTAP by default, which can cause share deletion problems in Manila. Manila will not be able to delete such shares, as the equivalent flexclone volumes remain linked in “volume clones” of the parent volume in ONTAP. To avoid waiting for the retention period and to delete the flexclone share immediately in OpenStack or ONTAP, set the retention period to 0 for the share server being used:

> set diagnostic

> vserver modify -vserver <vserver_name> -volume-delete-retention-hours 0

updated: 2026-04-23 11:35

This document is licensed under Apache 2.0 license.