Chapter 4. Shared File Systems service

With the Shared File Systems service (manila), you can provision shared file systems that multiple compute instances, bare metal nodes, or containers can consume. Cloud administrators create share types to prepare the share service and enable end users to create and manage shares.

Prerequisites

An end user requires at least one share type to use the Shared File Systems service.
For back ends where driver_handles_share_servers=False, a cloud administrator configures the requisite networking in advance rather than dynamically in the shared file system back end.
For a CephFS through NFS back end, a cloud administrator deploys Red Hat OpenStack Platform (RHOSP) director with isolated networks and environment arguments and a custom network_data file to create an isolated StorageNFS network for NFS exports. After deployment, before the overcloud is used, the administrator creates a corresponding Networking service (neutron) StorageNFS shared provider network that maps to the isolated StorageNFS network of the data center.
For a Compute instance to connect to this shared provider network, the user must add an additional neutron port.

Use the following concepts and procedures to understand and use the Shared File Systems service:

To choose a back end, see Section 4.1, “Shared File Systems service (manila) back ends”.
To understand your networking choices, see Section 4.1.1, “Networking for shared file systems”.
To create and manage shares, see:
To manage network connectivity, see:
- Section 4.2, “Ensuring network connectivity to the share”
- Section 4.2.1, “Connecting to a shared network to access shares”
To manage share access, see:
- Section 4.3.1, “Granting access to a share”
- Section 4.3.2, “Revoking access to a share”
To manage shares, see:
To manage quotas, see:
- Section 4.6.1, “Listing quotas”
To troubleshoot issues, see:
- Section 4.7.1, “Fixing create share or create share group failures”
- Section 4.7.2, “Debugging share mounting failures”

4.1. Shared File Systems service (manila) back ends

When cloud administrators use Red Hat OpenStack Platform (RHOSP) director to deploy the Shared File Systems service, they can choose one of the following supported back ends:

CephFS through NFS. For more information, see Deploying the Shared File Systems service with CephFS through NFS.
Native CephFS. For more information, see CephFS Back End Guide for the Shared File System Service.
NetApp. For more information, see the NetApp documentation: Shared File Systems Service (Manila).
Dell EMC Unity, Dell VNX, or Dell PowerMax. For more information, see the Dell documentation: Dell EMC Manila Backend Deployment Guide for Red Hat OpenStack Platform 16.

For a complete list of supported back-end appliances and drivers, see Component, Plug-In, and Driver Support in RHEL OpenStack Platform.

4.1.1. Networking for shared file systems

Shared file systems are accessed over a network. It is important to plan the networking on your cloud to ensure that end user clients can connect their shares to workloads that run on Red Hat OpenStack Platform (RHOSP) virtual machines, bare-metal servers, and containers.

Depending on the level of security and isolation required for end users, as an administrator, you can set the driver_handles_share_servers parameter to true or false.

If you set the driver_handles_share_servers parameter to true, this enables the service to export shares to end user-defined share networks with the help of isolated share servers.

When the driver_handles_share_servers parameter equals true, users can provision their workloads on self-service share networks. This ensures that their shares are exported by completely isolated NAS file servers on dedicated network segments.

The share networks used by end users can be the same as the private project networks that they can create. As an administrator, you must ensure that the physical network to which you map these isolated networks extends to your storage infrastructure.

You must also ensure that the network segmentation style by project networks is supported by the storage system used. Storage systems, such as NetApp ONTAP and Dell EMC PowerMax, Unity, and VNX, do not support virtual overlay segmentation styles such as GENEVE or VXLAN.

As an alternative, you can terminate the overlay networking at top-of-rack switches and use a more primitive form of networking for your project networks, such as VLAN. Another alternative is to allow VLAN segments on shared provider networks or provide access to a pre-existing segmented network that is already connected to your storage system.

If you set the driver_handles_share_servers parameter to false, users cannot create shares on their own share networks. Instead, they must connect their clients to the network configured by the cloud administrator.

When the driver_handles_share_servers parameter equals false, director can create a dedicated shared storage network for you. For example, when you deploy the native CephFS back end with standard director templates, director creates a shared provider network called Storage. When you deploy CephFS through the NFS back end, the shared provider network is called StorageNFS. Your end users must connect their clients to the shared storage network to access their shares.

Not all shared file system storage drivers support both modes of operation. Regardless of which mode you choose, the service ensures hard data path multi-tenancy isolation guarantees.

If you want to offer hard network path multi-tenancy isolation guarantees to tenant workloads as part of a self-service model, you must deploy with back ends that support the driver_handles_share_servers driver mode.

For information about network connectivity to the share, see Section 4.2, “Ensuring network connectivity to the share”

4.1.3. Common capabilities of share types

Share types define the common capabilities of shares. Review the common capabilities of share types to understand what you can do with your shares.

Table 4.1. Capabilities of share types
Capability	Values	Description
`driver_handles_share_servers`	true or false	Grants permission to use share networks to create shares.
`snapshot_support`	true or false	Grants permission to create snapshots of shares.
`create_share_from_snapshot_support`	true or false	Grants permission to create clones of share snapshots.
`revert_to_snapshot_support`	true or false	Grants permission to revert your shares to the most recent snapshot.
`mount_snapshot_support`	true or false	Grants permission to export and mount your snapshots.
`replication_type`	dr	Grants permission to create replicas for disaster recovery. Only one active export is allowed at a time.
	readable	Grants permission to create read-only replicas. Only one writable, active export is allowed at a time.
	writable	Grants permission to create read/write replicas. Any number of active exports are allowed at a time per share.
`availability_zones`	a list of one or more availability zones	Grants permission to create shares only on the availability zones listed.

4.1.5. Creating a share

Create a share to read and write data.

To create a share, use a command similar to the following:

$ manila create [--share-type <sharetype>] [--name <sharename>] proto GB

Replace the following values:

sharetype applies settings associated with the specified share type.
- Optional: if not supplied, the default share type is used.
sharename is the name of the share.
- Optional: shares are not required to have a name, nor is the name guaranteed to be unique.
proto is the share protocol you want to use.
- For CephFS with NFS, proto is nfs.
- For CephFS native, proto is cephfs.
- For NetApp and Dell EMC storage back ends, proto is nfs or cifs.
GB is the size of the share in gigabytes.

For example, in Section 4.1.2, “Creating a share type”, the cloud administrator created a default share type that selects a CephFS back end and another share type named netapp that selects a NetApp back end.

Procedure

Use the example share types to create a 10 GB NFS share named share-01 on the CephFS NFS back end. This example uses CephFS with NFS:
```
(user) [stack@undercloud-0 ~]$ manila create --name share-01 nfs 10
```

Optional: Create a 20 GB NFS share named share-02 on the NetApp back end:

(user) [stack@undercloud-0 ~]$ manila create --name share-02 --share-type netapp --share-network mynet nfs 20

4.1.6. Listing shares and exporting information

To verify that you successfully created the shares, complete the following steps.

Procedure

List the shares:

(user) [stack@undercloud-0 ~]$ manila list

+--------------------------------------+----------+-----+-----------+           | ID                                   | Name     | ... | Status    ...
+--------------------------------------+----------+-----+-----------+
| 8c3bedd8-bc82-4100-a65d-53ec51b5fe81 | share-01 | ... | available ...
+--------------------------------------+----------+-----+-----------+

View the export locations of the share:

(user) [stack@undercloud-0 ~]$ manila share-export-location-list share-01

 +------------------------------------------------------------------
 | Path
 |  172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01
 +------------------------------------------------------------------

View the parameters for the share:
```
manila share-export-location-show <id>
```
Note
This information is used to mount the share in Section 4.4.2, “Mounting the share”.

4.2. Ensuring network connectivity to the share

Clients that need to connect to a file share must have network connectivity to one or more of the export locations for that share.

There are many ways to configure networking with the Shared File Systems service, including using network plugins.

When the driver_handles_share_servers parameter for a share type equals true, a cloud user can create a share network with the details of a network to which the compute instance attaches and then reference it when creating shares.

When the driver_handles_share_servers parameter for a share type equals false, a cloud user must connect their compute instance to the shared storage network.

For more information about how to configure and validate network connectivity to a shared network, see Section 4.2.1, “Connecting to a shared network to access shares”.

4.2.1. Connecting to a shared network to access shares

When the driver_handles_share_servers parameter equals false, shares are exported to the shared provider network that the administrator made available. As an end user, you must connect your client, such as a Compute instance, to the shared provider network to access your shares.

In this example procedure, the shared provider network is called StorageNFS. StorageNFS is configured when director deploys the Shared File Systems service with the CephFS through NFS back end. Follow similar steps to connect to the network made available by your cloud administrator.

Note

In the example procedure, the IP address family version of the client is not important. The steps in this procedure use IPv4 addressing, but the steps are identical for IPv6.

Procedure

Create a security group for the StorageNFS port that allows packets to egress the port, but which does not allow ingress packets from unestablished connections:

(user) [stack@undercloud-0 ~]$ openstack security group create no-ingress -f yaml
created_at: '2018-09-19T08:19:58Z'
description: no-ingress
id: 66f67c24-cd8b-45e2-b60f-9eaedc79e3c5
name: no-ingress
project_id: 1e021e8b322a40968484e1af538b8b63
revision_number: 2
rules: 'created_at=''2018-09-19T08:19:58Z'', direction=''egress'', ethertype=''IPv4'',
 id=''6c7f643f-3715-4df5-9fef-0850fb6eaaf2'', updated_at=''2018-09-19T08:19:58Z''

 created_at=''2018-09-19T08:19:58Z'', direction=''egress'', ethertype=''IPv6'',                                                          id=''a8ca1ac2-fbe5-40e9-ab67-3e55b7a8632a'', updated_at=''2018-09-19T08:19:58Z'''
updated_at: '2018-09-19T08:19:58Z'

Create a port on the StorageNFS network with security enforced by the no-ingress security group.

(user) [stack@undercloud-0 ~]$ openstack port create nfs-port0 --network StorageNFS --security-group no-ingress -f yaml

admin_state_up: UP
allowed_address_pairs: ''
binding_host_id: null
binding_profile: null
binding_vif_details: null
binding_vif_type: null
binding_vnic_type: normal
created_at: '2018-09-19T08:03:02Z'
data_plane_status: null
description: ''
device_id: ''
device_owner: ''
dns_assignment: null
dns_name: null
extra_dhcp_opts: ''
fixed_ips: ip_address='172.17.5.160', subnet_id='7bc188ae-aab3-425b-a894-863e4b664192'
id: 7a91cbbc-8821-4d20-a24c-99c07178e5f7
ip_address: null
mac_address: fa:16:3e:be:41:6f
name: nfs-port0
network_id: cb2cbc5f-ea92-4c2d-beb8-d9b10e10efae
option_name: null
option_value: null
port_security_enabled: true
project_id: 1e021e8b322a40968484e1af538b8b63
qos_policy_id: null
revision_number: 6
security_group_ids: 66f67c24-cd8b-45e2-b60f-9eaedc79e3c5
status: DOWN
subnet_id: null
tags: ''
trunk_details: null
updated_at: '2018-09-19T08:03:03Z'

Note

StorageNFSSubnet assigned IP address 172.17.5.160 to nfs-port0.

Add nfs-port0 to a Compute instance.
```
(user) [stack@undercloud-0 ~]$ openstack server add port instance0 nfs-port0
(user) [stack@undercloud-0 ~]$ openstack server list -f yaml
- Flavor: m1.micro
  ID: 0b878c11-e791-434b-ab63-274ecfc957e8
  Image: manila-test
  Name: demo-instance0
  Networks: demo-network=172.20.0.4, 10.0.0.53; StorageNFS=172.17.5.160
  Status: ACTIVE
```
In addition to its private and floating addresses, the Compute instance is assigned a port with the IP address 172.17.5.160 on the StorageNFS network that you can use to mount NFS shares when access is granted to that address for the share in question.
Note
You might need to adjust the networking configuration on the Compute instance and restart the services for the Compute instance to activate an interface with this address.

4.2.2. Configuring an IPv6 interface between the network and an instance

When the shared network to which shares are exported uses IPv6 addressing, you might experience issues with DHCPv6 on the secondary interface. Use this procedure to configure an IPv6 interface manually on the instance. For more information, see BZ#1859695.

Prerequisites

Connect to a shared network to access shares.

Procedure

Configure the IPv6 interface address:

$ ip address add fd00:fd00:fd00:7000::c/64 dev eth1

Activate the interface:
```
$ ip link set dev eth1 up
```
Ping the IPv6 address in the export location of the share to test interface connectivity:
```
$ ping -6  fd00:fd00:fd00:7000::21
```
Alternatively, verify that you can reach the NFS server through Telnet:
```
$ dnf install -y telnet
$ telnet fd00:fd00:fd00:7000::21 2049
```

4.3. Grant share access

Before you can mount a share on a client, such as a compute instance, you must grant the client access to the share by using a command similar to the following:

# manila access-allow <share> <accesstype> --access-level <accesslevel>  <clientidentifier>

Replace the following values:

share - the share name or ID of the share created in Section 4.1.5, “Creating a share”.
accesstype - the type of access to be requested on the share. Some types include:
- user: use to authenticate by user or group name.
- ip: use to authenticate an instance through its IP address.
- cephx: use to authenticate by native CephFS client user name.
  Note
  The type of access depends on the protocol of the share. For NFS shares, only ip access type is allowed. For CIFS, user access type is appropriate. For native CephFS shares, you must use cephx.
accesslevel - optional, default is rw
- rw: read-write access to shares.
- ro: read-only access to shares.
clientidentifier - varies depending on accesstype.
- Use an IP address for ip accesstype.
- Use CIFS user or group for user accesstype.
- Use a user name string for cephx accesstype.

4.3.1. Granting access to a share

You must grant end user clients access to the share so that users can read data from and write data to the share.

Use this procedure to grant a client compute instance access to an NFS share through the IP address of the instance. The user rules for CIFS shares and cephx rules for CephFS shares follow a similar pattern. With user and cephx access types, you can use the same clientidentifier across multiple clients, if desired.

Note

In the example procedure, the IP address family version of the client is not important. The steps in this procedure use IPv4 addressing, but the steps are identical for IPv6.

Procedure

Retrieve the IP address of the client compute instance where you plan to mount the share. Make sure that you pick the IP address that corresponds to the network that can reach the shares. In this example, it is the IP address of the StorageNFS network:

(user) [stack@undercloud-0 ~]$ openstack server list -f yaml
- Flavor: m1.micro
  ID: 0b878c11-e791-434b-ab63-274ecfc957e8
  Image: manila-test
  Name: demo-instance0
  Networks: demo-network=172.20.0.4, 10.0.0.53;
  StorageNFS=172.17.5.160
  Status: ACTIVE

(user) [stack@undercloud-0 ~]$ manila access-allow share-01 ip 172.17.5.160

Note

Access to the share has its own ID (accessid).

+-----------------+---------------------------------------+
| Property        | Value                                 |
+-----------------+---------------------------------------+
| access_key      | None
| share_id        | db3bedd8-bc82-4100-a65d-53ec51b5cba3
| created_at      | 2018-09-17T21:57:42.000000
| updated_at      | None
| access_type     | ip
| access_to       | 172.17.5.160
| access_level    | rw
| state           | queued_to_apply
| id              | 875c6251-c17e-4c45-8516-fe0928004fff
+-----------------+---------------------------------------+

Verify that the access configuration was successful:

(user) [stack@undercloud-0 ~]$ manila access-list share-01

+--------------+-------------+--------------+--------------+--------+ ...
| id           | access_type | access_to    | access_level | state  | ...
+--------------+-------------+--------------+--------------+--------+
| 875c6251-... | ip          | 172.17.5.160 | rw       	   | active | ...
+--------------+------------+--------------+--------------+---------+ ...

4.3.2. Revoking access to a share

The owner of a share can revoke access to the share for any reason. Complete the following steps to revoke previously-granted access to a share.

Procedure

Revoke access to a share:

# manila access-deny <share> <accessid>

Note

Replace <share> with either the share name or the share ID.

For example:

(user) [stack@undercloud-0 ~]$ manila access-list share-01
+--------------+-------------+--------------+--------------+--------+
| id           | access_type | access_to    | access_level | state  | ...
+--------------+-------------+--------------+--------------+--------+ ...
| 875c6251-... | ip          | 172.17.5.160 | rw       	   | active | ...
+--------------+-------------+--------------+--------------+--------+

(user) [stack@undercloud-0 ~]$ manila access-deny share-01 875c6251-c17e-4c45-8516-fe0928004fff

(user) [stack@undercloud-0 ~]$ manila access-list share-01

+--------------+------------+--------------+--------------+--------+ ...
| id           | access_type| access_to    | access_level | state  | ...
+--------------+------------+--------------+--------------+--------+ ...
+--------------+------------+--------------+--------------+--------+ ...

Note

If you have an existing client that has read-write permissions, you must revoke their access to a share and add a read only rule if you want the client to have read-only permissions.

4.4. Mount share on compute instances

After you grant access to clients, shares can be mounted and used by them. Any type of client can access shares as long as there is network connectivity to the client.

The steps used to mount an NFS share on a virtual compute instance are similar to the steps to mount an NFS share on a bare metal compute instance. For more information about how to mount shares on OpenShift containers, see Product Documentation for OpenShift Container Platform.

Note

Client packages for the different protocols must be installed on the Compute instance that mounts the shares. For example, for the Shared File Systems service with CephFS through NFS, the NFS client packages must support NFS 4.1.

4.4.2. Mounting the share

Mount a share on the client to enable access to data.

For information about creating and granting share access, see the following procedures:

Procedure

(user) [stack@undercloud-0 ~]$ openstack server ssh demo-instance0 --login root
# hostname
demo-instance0

Mount the share on an IPv4 network by using the export location:

# mount -t nfs -v  172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01 /mnt

4.5. Deleting a share

The Shared File Systems service (manila) provides no protections to prevent you from deleting your data. The Shared File Systems service does not check whether clients are connected or workloads are running. When you delete a share, you cannot retrieve it.

WARNING: Back up your data before you delete a share.

Procedure

Delete a share:
```
# manila delete <share>
```
Note
In the example command, <share> can be either the share name or the share ID.
For example:
```
# manila delete share-01
```

4.6. Change the default quotas in the Shared File Systems service

To prevent system capacities from being exhausted without notification, cloud administrators can configure quotas. Quotas are operational limits.

4.6.1. Listing quotas

As a cloud administrator, you can list the quotas for a project or user by using the manila quota-show command. If you include the optional --user parameter, you can view the quota for this user in the specified project. If you omit this parameter, you get the quotas for the specified project.

You can update and delete quotas. You can update the shares, snapshots, gigabytes, snapshot-gigabytes, share-networks, share_groups,share_group_snapshots, and share-type quotas.

Procedure

To see the usage statements, run the following commands:

# manila help quota-show
# manila help quota-update
# manila help quota-delete

4.7. Troubleshooting failures

In the event that Shared File Systems (manila) operations, such as create share or create share group, fail asynchronously, as an end user, you can run queries from the command line for more information about the errors.

Chapter 4. Shared File Systems service

4.1. Shared File Systems service (manila) back ends

4.1.1. Networking for shared file systems

4.1.3. Common capabilities of share types

4.1.5. Creating a share

4.1.6. Listing shares and exporting information

4.2. Ensuring network connectivity to the share

4.2.1. Connecting to a shared network to access shares

4.2.2. Configuring an IPv6 interface between the network and an instance

4.4. Mount share on compute instances

4.4.2. Mounting the share

4.5. Deleting a share

4.6. Change the default quotas in the Shared File Systems service

4.6.1. Listing quotas

4.7. Troubleshooting failures

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links

Chapter 4. Shared File Systems service

4.1. Shared File Systems service (manila) back ends

4.1.1. Networking for shared file systems

4.1.2. Creating a share type

4.1.3. Common capabilities of share types

4.1.4. Discovering share types

4.1.5. Creating a share

4.1.6. Listing shares and exporting information

4.2. Ensuring network connectivity to the share

4.2.1. Connecting to a shared network to access shares

4.2.2. Configuring an IPv6 interface between the network and an instance

4.3. Grant share access

4.3.1. Granting access to a share

4.3.2. Revoking access to a share

4.4. Mount share on compute instances

4.4.1. Listing shares export locations

4.4.2. Mounting the share

4.5. Deleting a share

4.6. Change the default quotas in the Shared File Systems service

4.6.1. Listing quotas

4.7. Troubleshooting failures

4.7.1. Fixing create share or create share group failures

4.7.2. Debugging share mounting failures

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links