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

updated: 2026-10-28 05:41

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. The backend configuration is different depending on whether the driver manages share servers (driver_handles_share_servers=True, DHSS=True) or provisions shares directly on an existing SVM (driver_handles_share_servers=False, DHSS=False). A backend is always one or the other, never both; the two subsections below cover each mode on its own.

DHSS=False Backend¶

With DHSS=False, Manila provisions shares directly on the existing SVM named by netapp_vserver. Manila does not create the SVM, does not create or attach a share network, and does not configure any Manila security service on this SVM. Complete all SVM setup, including CIFS authentication, directly in ONTAP before Manila creates any shares.

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'
              replication_domain = netapp_replication_domain
              default_share_type = dhss_false
              backend_availability_zone=manila-zone-1
      ...

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

This example provisions NFS shares, because netapp_vserver points at an SVM configured for NFS. To provision CIFS shares instead, point netapp_vserver at a CIFS-enabled SVM:

  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=<cifs_vserver_name>
                replication_domain = netapp_replication_domain
                default_share_type = dhss_false
                backend_availability_zone=manila-zone-1
      ...

The driver reports storage_protocol as NFS_CIFS regardless of which protocol the SVM actually serves. There is no Manila configuration option that selects CIFS for a DHSS=False backend; the openstack share create command, at share creation time, selects the protocol, and it only succeeds if the SVM named by netapp_vserver is already configured for it.

Important

CIFS clients must authenticate. For a DHSS=False backend, Manila has no share network and configures no security service, so this must be done directly in ONTAP before creating any CIFS share, as described in ONTAP Prerequisites:

Enable the CIFS license and the CIFS service on the SVM.
Join the SVM to Active Directory, for example with vserver cifs create -vserver <svm> -cifs-server <name> -domain <domain>.
Set CIFS as a data protocol on the data LIF, and configure DNS so the SVM can resolve the Active Directory domain.

Only an Active Directory join creates a CIFS server on the SVM. An SVM configured for LDAP or Kerberos alone has no CIFS server and cannot authenticate CIFS clients by itself.

DHSS=True Backend¶

With DHSS=True, Manila creates one share server (an SVM) per share network, the first time a share is requested on that network. Do not set netapp_vserver; the driver names each SVM using netapp_vserver_name_template instead.

A DHSS=True backend also needs a network plugin, so the driver knows which IP addresses, VLAN, and gateway to use for each SVM’s data LIF:

Standalone Network Plugin – network settings come from manila.conf. Use this when the storage network is not managed by Neutron. See Manila Network Plugins: Standalone Network Plugin for the full option reference.
Neutron Network Plugin – network settings come from a Neutron network and subnet that already exist in Neutron. This is the more dynamic option, and is the one most RHOSO deployments should prefer. See Manila Network Plugins: Simple Neutron Network Plugin (one shared network for every share server on the backend) and Manila Network Plugins: Configurable Neutron Network Plugin (each tenant supplies their own network) for the full option reference.

Refer the following example for an NFS backend with DHSS=True, using the Standalone Network Plugin:

  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=True
                share_backend_name=netapp-ontap-backend
                share_driver=manila.share.drivers.netapp.common.NetAppDriver
                netapp_storage_family=ontap_cluster
                netapp_storage_protocol=nfs
                netapp_vserver_name_template=vs_osp_%s
                netapp_root_volume_aggregate=<data_aggregate_name>
                replication_domain = netapp_replication_domain
                backend_availability_zone=manila-zone-1
                network_api_class = manila.network.standalone_network_plugin.StandaloneNetworkPlugin
                standalone_network_plugin_allowed_ip_ranges = <start_ip>-<end_ip>
                standalone_network_plugin_gateway = <gateway_ip>
                standalone_network_plugin_mask = <network_mask>
                standalone_network_plugin_ip_version = 4
                standalone_network_plugin_network_type = flat
      ...

Use a data aggregate for netapp_root_volume_aggregate, not a root aggregate. Replace the Standalone Network Plug-in values with the values of your storage network.

To use the Neutron Network Plugin instead, create the Neutron network and subnet first, then replace the standalone_network_plugin_* lines above with:

network_api_class = manila.network.neutron.neutron_network_plugin.NeutronSingleNetworkPlugin
neutron_net_id = <neutron_network_id>
neutron_subnet_id = <neutron_subnet_id>

With this plugin, tenants create empty share networks, without supplying any Neutron network information of their own; every share server on this backend uses the neutron_net_id and neutron_subnet_id configured here. Use the Configurable Neutron Network Plugin instead if each tenant needs to choose their own Neutron network or subnet.

This example provisions NFS shares. To provision CIFS shares instead, use the following example:

  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=True
                share_backend_name=netapp-ontap-backend
                share_driver=manila.share.drivers.netapp.common.NetAppDriver
                netapp_storage_family=ontap_cluster
                netapp_vserver_name_template=vs_osp_%s
                netapp_root_volume_aggregate=<data_aggregate_name>
                replication_domain = netapp_replication_domain
                backend_availability_zone=manila-zone-1
                network_api_class = manila.network.standalone_network_plugin.StandaloneNetworkPlugin
                standalone_network_plugin_allowed_ip_ranges = <start_ip>-<end_ip>
                standalone_network_plugin_gateway = <gateway_ip>
                standalone_network_plugin_mask = <network_mask>
                standalone_network_plugin_ip_version = 4
                standalone_network_plugin_network_type = flat
                netapp_cifs_aes_encryption = True
                netapp_cifs_smb_signing = True
      ...

Keep netapp_vserver_name_template free of characters that are illegal in a DNS hostname; the driver uses it to name the CIFS server as well as the SVM. netapp_enabled_share_protocols only lists NFS protocol versions (nfs3, nfs4.0, nfs4.1); it has no effect on CIFS.

netapp_cifs_aes_encryption and netapp_cifs_smb_signing are CIFS-only options, applied when the driver joins a new SVM to Active Directory:

netapp_cifs_aes_encryption enables AES encryption for Kerberos communication with the CIFS server. Default False.
netapp_cifs_smb_signing requires SMB signing on the CIFS server. Default False.

Important

CIFS clients must authenticate, and for a DHSS=True backend, Manila drives that through a security service attached to the share network. Create an active_directory security service and attach it to the share network before creating the first CIFS share on that network:

sh-5.1$ openstack share security service create active_directory \
  --dns-ip <dns_ip> --domain <domain> --user <ad_user> \
  --password <ad_password> --name rhoso_ad
sh-5.1$ openstack share network create --name rhoso_cifs_share_network
sh-5.1$ openstack share network set rhoso_cifs_share_network \
  --new-security-service rhoso_ad

When the first share is created on rhoso_cifs_share_network, the driver joins the new SVM to Active Directory using this security service. Without a security service on the share network, the new SVM has no CIFS server and shares on that network cannot be created or accessed.

Only an active_directory security service makes the driver create a CIFS server. ldap and kerberos security services configure NFS name services and NFS Kerberos; they do not create a CIFS server and cannot authenticate CIFS clients by themselves. A share network can have one security service of each type, so pairing active_directory with ldap or kerberos on the same network is supported if NFS shares on that network also need those services.

Note

Every DHSS=True share is created on a share server, and each share server consumes a share network. The default share_networks quota is 10. If you need more share networks, raise the quota in the Manila template:

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>

For a DHSS=True backend, omit netapp_vserver from this file and supply the cluster management credentials only.

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

Test the Deployed NFS Back End with DHSS=True¶

A DHSS=True back end needs a share type with driver_handles_share_servers=True and a share network. Manila creates the share server, and therefore the SVM, when the first share is created on that share network. Run the following commands inside the openstackclient pod:

[root@rhel92-rhosp ~]# oc rsh openstackclient
sh-5.1$ openstack share type create dhss_true true
sh-5.1$ openstack share type set dhss_true --extra-specs snapshot_support=True \
  create_share_from_snapshot_support=True revert_to_snapshot_support=True
sh-5.1$ openstack share network create --name rhoso_nfs_share_network
sh-5.1$ openstack share create --share-type dhss_true \
  --share-network rhoso_nfs_share_network --name rhoso_nfs_dhss_true NFS 1
sh-5.1$ openstack share show rhoso_nfs_dhss_true
sh-5.1$ openstack share access create rhoso_nfs_dhss_true ip <client_ip> \
  --access-level rw

The share reaches the available status once the share server is created. The export locations report the data LIF addresses that the driver allocated from standalone_network_plugin_allowed_ip_ranges, in the form <lif_ip>:/share_<share_instance_id>. Use an export location to mount the share from a client that is permitted by the access rule.

Test the Deployed CIFS Back End¶

DHSS=False¶

Create the share type with driver_handles_share_servers=False. The SVM named by netapp_vserver must already be joined to Active Directory. Run the following commands inside the openstackclient pod:

[root@rhel92-rhosp ~]# oc rsh openstackclient
sh-5.1$ openstack share create --share-type default \
  --name rhoso_cifs_dhss_false CIFS 1
sh-5.1$ openstack share show rhoso_cifs_dhss_false
sh-5.1$ openstack share access create rhoso_cifs_dhss_false user \
  <domain>\<user> --access-level rw

The access rule type is user. The account must exist in the Active Directory domain the SVM is joined to. The export location is a UNC path, \\<lif_ip>\share_<share_instance_id>.

DHSS=True¶

A DHSS=True back end needs a share type with driver_handles_share_servers=True, a share network, and an Active Directory security service on that share network. Run the following commands inside the openstackclient pod:

[root@rhel92-rhosp ~]# oc rsh openstackclient
sh-5.1$ openstack share type create dhss_true true
sh-5.1$ openstack share type set dhss_true --extra-specs snapshot_support=True \
  create_share_from_snapshot_support=True revert_to_snapshot_support=True
sh-5.1$ openstack share security service create active_directory \
  --dns-ip <dns_ip> --domain <domain> --user <ad_user> \
  --password <ad_password> --name rhoso_ad
sh-5.1$ openstack share network create --name rhoso_cifs_share_network
sh-5.1$ openstack share network set rhoso_cifs_share_network \
  --new-security-service rhoso_ad
sh-5.1$ openstack share create --share-type dhss_true \
  --share-network rhoso_cifs_share_network --name rhoso_cifs_dhss_true CIFS 1
sh-5.1$ openstack share show rhoso_cifs_dhss_true
sh-5.1$ openstack share access create rhoso_cifs_dhss_true user \
  <domain>\<user> --access-level rw

The share reaches the available status once the share server is created and the SVM is joined to Active Directory. The export location is a UNC path, \\<lif_ip>\share_<share_instance_id>. The Standalone Network Plug-in allocates the data LIF address from standalone_network_plugin_allowed_ip_ranges.

updated: 2026-10-28 05:41

This document is licensed under Apache 2.0 license.