Chapter 6. Configuring the Shared File Systems service (manila)
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.
6.1. Shared File Systems service back ends
When cloud administrators use Red Hat OpenStack Platform (RHOSP) director to deploy the Shared File Systems service (manila), they can choose one or more 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 Deploying the Shared File Systems service with native CephFS.
- 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.
6.1.1. Using multiple back ends
A back end is a storage system or technology that is paired with the Shared File Systems service (manila) driver to export file systems. The Shared File Systems service requires at least one back end to operate. In many cases, one back end is sufficient. However, you can also use multiple back ends in a single Shared File Systems service installation.
Currently, Red Hat OpenStack Platform (RHOSP) does not support multiple instances of the same back end to a Shared File Systems service deployment. For example, you cannot add two Ceph Storage clusters as back ends within the same deployment. The back ends that you choose must be heterogeneous. CephFS native and CephFS through NFS are considered one back end with different protocols.
The scheduler for the Shared File Systems service determines the destination back end for share creation requests. A single back end in the Shared File Systems service can expose multiple storage pools.
When you configure multiple back ends, the scheduler chooses one storage pool to create a resource from all the pools exposed by all configured back ends. This is abstracted from the end user. End users see only the capabilities that are exposed by the cloud administrator.
6.1.2. Deploying multiple back ends
By default, a standard Shared File Systems deployment environment file has a single back end. Use the following example procedure to add multiple back ends to the Shared File Systems service (manila) and deploy an environment with a CephFS-Ganesha and a NetApp back end.
Prerequisites
- At least two back ends.
- If a back end requires a custom container, you must use one from the Red Hat Ecosystem Catalog instead of the standard Shared File Systems service container. For example, if you want to use a Dell EMC Unity storage system back end with Ceph, choose the Dell EMC Unity container from the catalog.
Procedure
Create a storage customization YAML file. You can use this file to provide any values or overrides that suit your environment:
$ vi /home/stack/templates/storage_customizations.yaml
Configure the storage customization YAML file to include any overrides, including enabling multiple back ends:
parameter_defaults: ManilaEnabledShareProtocols: - NFS ManilaNetappLogin: '<login_name>' ManilaNetappPassword: '<password>' ManilaNetappServerHostname: '<netapp-hostname>' ManilaNetappVserver: ‘<netapp-vserver>’ ManilaNetappDriverHandlesShareServers: 'false'
Specify the back-end templates by using the
openstack overcloud deploy
command. The example configuration enables the Shared File Systems service with a NetApp back end and a CephFS through NFS back end.NoteExecute
source ~/stackrc
before issuing theopenstack overcloud deploy
command.[stack@undercloud ~]$ source ~/stackrc $ openstack overcloud deploy \ --timeout 100 \ --stack overcloud \ --templates /usr/share/openstack-tripleo-heat-templates \ -n /usr/share/openstack-tripleo-heat-templates/network_data_ganesha.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \ -r /home/stack/templates/roles/roles_data.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml \ -e /home/stack/templates/storage_customizations.yaml \ ...
Additional resources
-
For more information about the
ManilaEnabledShareProtocols
parameter, see Section 6.1.4, “Overriding allowed NAS protocols”. - For more information about the deployment command, see Director Installation and Usage.
6.1.3. Confirming deployment of multiple back ends
Use the manila service-list
command to verify that your back ends deployed successfully. If you use a health check on multiple back ends, a ping test returns a response even if one of the back ends is unresponsive, so this is not a reliable way to verify your deployment.
Procedure
-
Log in to the undercloud host as the
stack
user. Source the
overcloudrc
credentials file:$ source ~/overcloudrc
Confirm the list of Shared File Systems service back ends:
$ manila service-list +----+--------+--------+------+---------+-------+----------------------------+ | Id | Binary | Host | Zone | Status | State | Updated_at | +----+--------+--------+------+---------+-------+----------------------------+ | 2 | manila-scheduler | hostgroup | nova | enabled | up | 2021-03-24T16:49:09.000000 | | 5 | manila-share | hostgroup@cephfs | nova | enabled | up | 2021-03-24T16:49:12.000000 | | 8 | manila-share | hostgroup@tripleo_netapp | nova | enabled | up | 2021-03-24T16:49:06.000000 |
The status of each successfully deployed back end shows
enabled
and the state showsup
.
6.1.4. Overriding allowed NAS protocols
The Shared File Systems service can export shares in one of many network attached storage (NAS) protocols, such as NFS, CIFS, or CEPHFS. By default, the Shared File Systems service enables all of the NAS protocols supported by the back ends in a deployment.
As a Red Hat OpenStack Platform (RHOSP) administrator, you can override the ManilaEnabledShareProtocols
parameter and list only the protocols that you want to allow in your cloud.
For example, if back ends in your deployment support both NFS and CIFS, you can override the default value and enable only one protocol.
Procedure
-
Log in to the undercloud host as the
stack
user. Source the
overcloudrc
credentials file:$ source ~/overcloudrc
Create a storage customization YAML file. This file can be used to provide any values or overrides that suit your environment:
$ vi /home/stack/templates/storage_customizations.yaml
Configure the
ManilaEnabledShareProtocols
parameter with the values that you want:parameter_defaults: ManilaEnabledShareProtocols: - NFS - CEPHFS
Include the environment file that contains your new content in the
openstack overcloud deploy
command by using the-e
option. Ensure that you include all other environment files that are relevant to your deployment.$ openstack overcloud deploy \ ... -e /home/stack/templates/storage_customizations.yaml
NoteThe deployment does not validate the settings. The NAS protocols that you assign must be supported by the back ends in your Shared File Systems service deployment.
6.1.5. Viewing back-end capabilities
The scheduler component of the Shared File Systems service (manila) makes intelligent placement decisions based on several factors such as capacity, provisioning configuration, placement hints, and the capabilities that the back-end storage system driver detects and exposes.
Procedure
Run the following command to view the available capabilities:
$ manila pool-list --detail +------------------------------------+----------------------------+ | Property | Value | +------------------------------------+----------------------------+ | name | hostgroup@cephfs#cephfs | | pool_name | cephfs | | total_capacity_gb | 1978 | | free_capacity_gb | 1812 | ... | driver_handles_share_servers | False | | snapshot_support | True | | create_share_from_snapshot_support | False | | revert_to_snapshot_support | False | | mount_snapshot_support | False | ... +------------------------------------+----------------------------+ +------------------------------------+-----------------------------------+ | Property | Value | +------------------------------------+-----------------------------------+ | name | hostgroup@tripleo_netapp#aggr1_n1 | | pool_name | aggr1_n1 | | total_capacity_gb | 6342.1 | | free_capacity_gb | 6161.99 | ... | driver_handles_share_servers | False | | mount_snapshot_support | False | | replication_type | None | | replication_domain | None | | sg_consistent_snapshot_support | host | | ipv4_support | True | | ipv6_support | False | +------------------------------------+-----------------------------------+ +------------------------------------+-----------------------------------+ | Property | Value | +------------------------------------+-----------------------------------+ | name | hostgroup@tripleo_netapp#aggr1_n2 | | pool_name | aggr1_n2 | | total_capacity_gb | 6342.1 | | free_capacity_gb | 6209.26 | ... | snapshot_support | True | | create_share_from_snapshot_support | True | | revert_to_snapshot_support | True | | driver_handles_share_servers | False | | mount_snapshot_support | False | | replication_type | None | | replication_domain | None | | sg_consistent_snapshot_support | host | | ipv4_support | True | | ipv6_support | False | +------------------------------------+-----------------------------------+
Related information
To influence placement decisions, as an administrator, you can use share types and extra specifications. For more information about share types, see Creating a share type.
6.2. Creating a share type
Cloud administrators can create share types to define the type of service that the Shared File Systems service (manila) scheduler uses to make scheduling decisions and that drivers use to control share creation.
Share types include a description and extra specifications, for example, driver_handles_share_servers
and snapshot_support
, to filter back ends. Red Hat OpenStack Platform (RHOSP) director configures the Shared File Systems service with a default share type named default
, but director does not create the share type.
Cloud users require at least one share type to use the Shared File Systems service, and users can only create shares that match the available share types.
By default, share types are public, which means they are available to all cloud projects. However, you can create private share types for use within specific projects.
In the following example procedure, you use the driver_handles_share_servers
parameter (DHSS), which you can set to true
or false
:
-
For CephFS-NFS and native CephFS, you set DHSS to
false
. -
For other back ends, you can set DHSS to
true
orfalse
. You set the DHSS value to match the value of theManila<backend>DriverHandlesShareServers
parameter in your storage customization environment file. For example, if you use a NetApp back end, this parameter isManilaNetappDriverHandlesShareServers
.
Procedure
After you deploy the overcloud, run the following command to create a share type:
$ manila type-create default <driver_handles_share_servers>
-
Replace
<driver_handles_share_servers>
withtrue
orfalse
.
-
Replace
Add specifications to the default share type or create additional share types to use with different back ends. In this example, configure the default share type to select a CephFS back end and an additional share type that uses a NetApp
driver_handles_share_servers=true
back end:$ manila type-create default false \ --extra-specs share_backend_name='cephfs' \ $ manila type-create netapp true \ --extra-specs share_backend_name='tripleo_netapp'
Additional resources
- For more information about how to make private share types or set additional share-type options, see the Security and Hardening Guide.
6.2.1. 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 6.1. Capabilities of share types
Capability | Values | Description |
---|---|---|
| true or false | Grants permission to use share networks to create shares. |
| true or false | Grants permission to create snapshots of shares. |
| true or false | Grants permission to create clones of share snapshots. |
| true or false | Grants permission to revert your shares to the most recent snapshot. |
| true or false | Grants permission to export and mount your snapshots. |
| 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. | |
| a list of one or more availability zones | Grants permission to create shares only on the availability zones listed. |
6.2.2. Discovering share types
As a cloud user, you must specify a share type when you create a share.
Procedure
Discover the available share types:
$ manila type-list
The command output lists the name and ID of the share type.
6.3. 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.
-
Optional: if not supplied, the
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
isnfs
. -
For CephFS native,
proto
iscephfs
. -
For NetApp and Dell EMC storage back ends,
proto
isnfs
orcifs
.
-
For CephFS with NFS,
-
GB
is the size of the share in gigabytes.
For example, in Section 6.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
6.3.1. 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>
NoteYou use the export location to mount the share in Section 6.9.2, “Mounting the share”.
6.4. Creating a snapshot of data on a shared file system
A snapshot is a read-only, point-in-time copy of data on a share. You can use a snapshot to recover data lost through accidental data deletion or file system corruption. Snapshots are more space efficient than backups, and they do not impact the performance of the Shared File Systems service (manila).
Prerequisites
The
snapshot_support
parameter must equaltrue
on the parent share. You can run the following command to verify:$ manila show | grep snapshot_support
Procedure
As a cloud user, create a snapshot of a share:
$ manila snapshot-create [--name <snapshot_name>] <share>
-
Replace
<share>
with the name or ID of the share for which you want to create a snapshot. Optional: Replace
<snapshot_name>
with the name of the snapshot.Example output
+-------------------+--------------------------------------+ | Property | Value | +-------------------+--------------------------------------+ | id | dbdcb91b-82ba-407e-a23d-44ffca4da04c | | share_id | ee7059aa-5887-4b87-b03e-d4f0c27ed735 | | share_size | 1 | | created_at | 2022-01-07T14:20:55.541084 | | status | creating | | name | snapshot_name | | description | None | | size | 1 | | share_proto | NFS | | provider_location | None | | user_id | 6d414c62237841dcbe63d3707c1cdd90 | | project_id | 041ff9e24eba469491d770ad8666682d | +-------------------+--------------------------------------+
-
Replace
Confirm that you created the snapshot:
$ manila snapshot-list --share-id <share>
Replace
<share>
with the name or ID of the share from which you created the snapshot.
6.5. Creating a share from a snapshot
You can create a share from a snapshot. If the parent share the snapshot was created from has a share type with driver_handles_share_servers
set to true
, the new share is created on the same share network as the parent.
If the share type of the parent share has driver_handles_share_servers
set to true
, you cannot change the share network for the share you create from the snapshot.
Prerequisites
The
create_share_from_snapshot_support
share attribute is set totrue
.For more information about share types, see Common capabilities of share types.
-
The
status
attribute of the snapshot is set toavailable
.
Procedure
Retrieve the ID of the share snapshot that contains the data that you require for your new share:
$ manila snapshot-list
A share created from a snapshot can be larger, but not smaller, than the snapshot. Retrieve the size of the snapshot:
$ manila snapshot-show <snapshot-id>
Create a share from a snapshot:
$ manila create <share_protocol> <size> \ --snapshot-id <snapshot_id> \ --name <name>
-
Replace
<share_protocol>
with the protocol, such as NFS. -
Replace
<size>
with the size of the share to be created, in GiB. -
Replace
<snapshot_id>
with the ID of the snapshot. -
Replace
<name>
with the name of the new share.
-
Replace
List the shares to confirm that the share was created successfully:
$ manila list
View the properties of the new share:
$ manila show <name>
Verification
After you create a snapshot, confirm that the snapshot is available.
List the snapshots to confirm that they are available:
$ manila snapshot-list
6.6. Deleting a snapshot
When you create a snapshot of a share, you cannot delete the share until you delete all of the snapshots created from that share.
Procedure
Identify the snapshot you want to delete and retrieve its ID:
$ manila snapshot-list
Delete the snapshot:
$ manila snapshot-delete <snapshot>
NoteRepeat this step for each snapshot that you want to delete.
After you delete the snapshot, run the following command to confirm that you deleted the snapshot:
$ manila snapshot-list
6.7. 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 6.7.1, “Ensuring network connectivity to the share”.
6.7.1. 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 6.7.2, “Connecting to a shared network to access shares”.
6.7.2. 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.
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'
NoteStorageNFSSubnet
assigned IP address 172.17.5.160 tonfs-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.
NoteYou 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.
6.7.3. 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 an issue with DHCPv6 on the secondary interface. If this issue occurs, configure an IPv6 interface manually on the instance.
Prerequisites
- Connection to a shared network to access shares
Procedure
- Log in to the instance.
Configure the IPv6 interface address:
$ sudo ip address add fd00:fd00:fd00:7000::c/64 dev eth1
Activate the interface:
$ sudo 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:
$ sudo dnf install -y telnet $ telnet fd00:fd00:fd00:7000::21 2049
6.8. 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 6.3, “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.NoteThe 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 usecephx
.
-
accesslevel
- optional, default isrw
-
rw
: read-write access to shares. -
ro
: read-only access to shares.
-
clientidentifier
- varies depending onaccesstype
.-
Use an IP address for
ip
accesstype
. -
Use CIFS user or group for
user
accesstype
. -
Use a user name string for
cephx accesstype
.
-
Use an IP address for
6.8.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.
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
NoteAccess 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 | ... +--------------+------------+--------------+--------------+---------+ ...
6.8.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>
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 | ... +--------------+------------+--------------+--------------+--------+ ... +--------------+------------+--------------+--------------+--------+ ...
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.
6.9. 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.
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.
6.9.1. Listing shares export locations
Retrieve the export locations of shares so that you can mount a share.
Procedure
Retrieve the export location of a share:
(user) [stack@undercloud-0 ~]$ manila share-export-location-list share-01
When multiple export locations exist, choose one for which the value of the
preferred
metadata field equals True. If no preferred locations exist, you can use any export location.
6.9.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
Log in to the instance and run the following command:
(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
6.10. 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.
Back up your data before you delete a share.
Prerequisites
- If you created snapshots from a share, you must delete all of the snapshots and replicas before you can delete the share. For more information, see Deleting a snapshot.
Procedure
Delete a share:
$ manila delete <share>
Replace
<share>
with either the share name or the share ID.
6.11. Changing 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. The Shared File Systems service (manila) enforces some sensible limits by default. These limits are called default quotas. Cloud administrators can override default quotas so that individual projects have different consumption limits.
6.11.1. Listing resource limits of the Shared File Systems service
As a cloud user, you can list the current resource limits. This can help you plan workloads and prepare for any action based on your resource consumption.
Procedure
List the resource limits and current resource consumption for the project:
$ manila absolute-limits +------------------------------+-------+ | Name | Value | +------------------------------+-------+ | maxTotalReplicaGigabytes | 1000 | | maxTotalShareGigabytes | 1000 | | maxTotalShareGroupSnapshots | 50 | | maxTotalShareGroups | 49 | | maxTotalShareNetworks | 10 | | maxTotalShareReplicas | 100 | | maxTotalShareSnapshots | 50 | | maxTotalShares | 50 | | maxTotalSnapshotGigabytes | 1000 | | totalReplicaGigabytesUsed | 22 | | totalShareGigabytesUsed | 25 | | totalShareGroupSnapshotsUsed | 0 | | totalShareGroupsUsed | 9 | | totalShareNetworksUsed | 2 | | totalShareReplicasUsed | 9 | | totalShareSnapshotsUsed | 4 | | totalSharesUsed | 12 | | totalSnapshotGigabytesUsed | 4 | +------------------------------+-------+
6.11.2. Updating quotas for projects, users, and share types
As a cloud administrator, you can list the quotas for a project or user by using the manila quota-show
command.
You can update quotas for all users in a project, or a specific project user, or a share type used by the project users. You can update the following quotas for the target you choose:
-
shares
: Number of shares that you can create. -
snapshots
: Number of snapshots that you can create. -
gigabytes
: Total size in GB that you can allocate for all shares. -
snapshot-gigabytes
: Total size in GB that you can allocate for all snapshots of shares. -
share-networks
: Total number of share networks that you can create. -
share_groups
: Total number of share groups that you can create. -
share_group_snapshots
: Total number of share group snapshots that you can create. -
share-replicas
: Total number of share replicas that you can create. -
replica-gigabytes
: Total size in GB that you can allocate across all share replicas.
You can only specify share-type
quotas at the project level. You cannot set share-type
quotas for specific project users.
In the following procedures, enter the values carefully. The Shared File Systems service does not detect or report incorrect values.
Procedure
You can use the following commands to view quotas. If you include the
--user
option, you can view the quota for a specific user in the specified project. If you omit the--user
option, you can view the quotas that apply to all users for the specified project.Similarly, if you include the optional
--share-type
, you can view the quota for a specific share type as it relates to the project. The--user
and--share-type
options are mutually exclusive.$ manila quota-show
Example for a project:
$ manila quota-show --project af2838436f3f4cf6896399dd97c4c050 +-----------------------+----------------------------------+ | Property | Value | +-----------------------+----------------------------------+ | gigabytes | 1000 | | id | af2838436f3f4cf6896399dd97c4c050 | | replica_gigabytes | 1000 | | share_group_snapshots | 50 | | share_groups | 49 | | share_networks | 10 | | share_replicas | 100 | | shares | 50 | | snapshot_gigabytes | 1000 | | snapshots | 50 | +-----------------------+----------------------------------+
Example for a project user:
$ manila quota-show --project af2838436f3f4cf6896399dd97c4c050 --user 81ebb491dd0e4c2aae0775dd564e76d1 +-----------------------+----------------------------------+ | Property | Value | +-----------------------+----------------------------------+ | gigabytes | 500 | | id | af2838436f3f4cf6896399dd97c4c050 | | replica_gigabytes | 1000 | | share_group_snapshots | 50 | | share_groups | 49 | | share_networks | 10 | | share_replicas | 100 | | shares | 25 | | snapshot_gigabytes | 1000 | | snapshots | 50 | +-----------------------+----------------------------------+
Example for a project for a specific share type:
$ manila quota-show --project af2838436f3f4cf6896399dd97c4c050 --share-type dhss_false +---------------------+----------------------------------+ | Property | Value | +---------------------+----------------------------------+ | gigabytes | 1000 | | id | af2838436f3f4cf6896399dd97c4c050 | | replica_gigabytes | 1000 | | share_replicas | 100 | | shares | 15 | | snapshot_gigabytes | 1000 | | snapshots | 50 | +---------------------+----------------------------------+
Use the
manila quota-update
command to update the quotas. You can update quotas for all project users, a specific project user, or a share type in a project:Update quotas for all users in a project:
$ manila quota-update <id> [--shares <share_quota> --gigabytes <share_gigabytes_quota> …]
Replace
<id>
with the project ID.Update quotas for a specific user in a project:
$ manila quota-update <id> --user <user_id> [--shares <new_share_quota> --gigabytes <new_share_gigabytes_quota> …]
-
Replace
<id>
with the project ID. This value must be the project ID, not the project name. -
Replace
<user_id>
with the user ID. The value must be the user ID, not the user name.
-
Replace
Update quotas for all users who use a specific share type:
$ manila quota-update <id> --share-type <share_type> [--shares <new_share_quota>30 --gigabytes <new-share_gigabytes_quota> …]
-
Replace
<id>
with the project ID. This value must be the project ID, not the project name. -
Replace
<share_type>
with the name or ID of the share type that you want to apply the quota to.
-
Replace
Verification
-
The
quota-update
command does not produce any output. Use thequota-show
command to verify that a quota was successfully updated.
6.11.3. Resetting quotas in the Shared File Systems service
You can remove quota overrides to return quotas to their default values. The target entity is restricted by the default quota that applies to all projects with no overrides.
Procedure
Use the
manila quota-delete
command to return quotas to default values. You can return quotas to default values for all project users, a specific project user, or a share type in a project:Reset project quotas:
$ manila quota-delete --project <id>
Replace
<id>
with the project ID. This value must be the project ID, not the project name.Reset quotas for a specific user:
$ manila quota-delete --project <id> --user <user_id>
-
Replace
<id>
with the project ID. This value must be the project ID, not the project name. -
Replace
<user_id>
with the user ID. The value must be the user ID, not the user name.
-
Replace
Reset quotas for a share type used by project users:
$ manila quota-delete --project <id> --share-type <share_type>
-
Replace
<id>
with the project ID. This value must be the project ID, not the project name. -
Replace
<share_type>
with the name or ID of the share type the quota must be reset for.
-
Replace
Verification
-
The
quota-delete
command does not produce any output. Use thequota-show
command to verify whether a quota was successfully reset. List the default quotas for all projects. Default quotas apply to projects that have no overrides.
$ manila quota-class-show default
6.11.4. Updating default quotas of the Shared File Systems service
As a cloud administrator, you can update default quotas that apply to all projects that do not already have quota overrides.
Procedure
View the usage statement of the
manila quota-class-update
command:$ manila help quota-class-update usage: manila quota-class-update [--shares <shares>] [--snapshots <snapshots>] [--gigabytes <gigabytes>] [--snapshot-gigabytes <snapshot_gigabytes>] [--share-networks <share_networks>] [--share-replicas <share_replicas>] [--replica-gigabytes <replica_gigabytes>] <class_name>
NoteThe parameter
<class_name>
is a positional argument. It identifies the quota class for which the quotas are set. Set the value of this parameter todefault
. No other quota classes are supported.You can update the values for any of the following optional parameters:
-
--shares <shares>
Adds a new value for theshares
quota. -
--snapshots <snapshots>
Adds a new value for thesnapshots
quota. -
--gigabytes <gigabytes>
Adds a new value for thegigabytes
quota. -
--snapshot-gigabytes <snapshot_gigabytes>
or--snapshot_gigabytes <snapshot_gigabytes>
Adds a new value for thesnapshot_gigabytes
quota. -
--share-networks <share_networks>
or--share_networks <share_networks>
Adds a new value for theshare_networks
quota. -
--share-replicas <share_replicas>
,--share_replicas <share_replicas>
, or--replicas <share_replicas>
Adds a new value for theshare_replicas
quota. -
--replica-gigabytes <replica_gigabytes>
or--replica_gigabytes <replica_gigabytes>
Adds a new value for thereplica_gigabytes
quota.
-
Use the information from the usage statement to update the default quotas. The following example updates the default quotas for
shares
andgigabytes
:$ manila quota-class-update default --shares 30 --gigabytes 512 $ manila quota-class-show default +-----------------------+---------+ | Property | Value | +-----------------------+---------+ | gigabytes | 512 | | id | default | | replica_gigabytes | 1000 | | share_group_snapshots | 50 | | share_groups | 50 | | share_networks | 10 | | share_replicas | 100 | | shares | 30 | | snapshot_gigabytes | 1000 | | snapshots | 50 | +-----------------------+---------+
6.12. 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.
6.12.1. Fixing create share or create share group failures
In this example, the goal of the end user is to create a share to host software libraries on several virtual machines. The example deliberately introduces two share creation failures to illustrate how to use the command line to retrieve user support messages.
Procedure
To create the share, you can use a share type that specifies some capabilities that you want the share to have. Cloud administrators can create share types. View the available share types:
clouduser1@client:~$ manila type-list +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+ | ID | Name | visibility | is_default | required_extra_specs | optional_extra_specs | Description | +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+ | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 | dhss_false | public | YES | driver_handles_share_servers : False | create_share_from_snapshot_support : True | None | | | | | | | mount_snapshot_support : False | | | | | | | | revert_to_snapshot_support : False | | | | | | | | snapshot_support : True | | | 277c1089-127f-426e-9b12-711845991ea1 | dhss_true | public | - | driver_handles_share_servers : True | create_share_from_snapshot_support : True | None | | | | | | | mount_snapshot_support : False | | | | | | | | revert_to_snapshot_support : False | | | | | | | | snapshot_support : True | | +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
In this example, two share types are available.
To use a share type that specifies the
driver_handles_share_servers=True
capability, you must create a share network on which to export the share. Create a share network from a private project network.clouduser1@client:~$ openstack subnet list +--------------------------------------+---------------------+--------------------------------------+---------------------+ | ID | Name | Network | Subnet | +--------------------------------------+---------------------+--------------------------------------+---------------------+ | 78c6ac57-bba7-4922-ab81-16cde31c2d06 | private-subnet | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 | 10.0.0.0/26 | | a344682c-718d-4825-a87a-3622b4d3a771 | ipv6-private-subnet | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 | fd36:18fc:a8e9::/64 | +--------------------------------------+---------------------+--------------------------------------+---------------------+ clouduser1@client:~$ manila share-network-create --name mynet --neutron-net-id 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 --neutron-subnet-id 78c6ac57-bba7-4922-ab81-16cde31c2d06 +-------------------+--------------------------------------+ | Property | Value | +-------------------+--------------------------------------+ | network_type | None | | name | mynet | | segmentation_id | None | | created_at | 2018-10-09T21:32:22.485399 | | neutron_subnet_id | 78c6ac57-bba7-4922-ab81-16cde31c2d06 | | updated_at | None | | mtu | None | | gateway | None | | neutron_net_id | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 | | ip_version | None | | cidr | None | | project_id | cadd7139bc3148b8973df097c0911016 | | id | 0b0fc320-d4b5-44a1-a1ae-800c56de550c | | description | None | +-------------------+--------------------------------------+ clouduser1@client:~$ manila share-network-list +--------------------------------------+-------+ | id | name | +--------------------------------------+-------+ | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 | mynet | +--------------------------------------+-------+
Create the share:
clouduser1@client:~$ manila create nfs 1 --name software_share --share-network mynet --share-type dhss_true +---------------------------------------+--------------------------------------+ | Property | Value | +---------------------------------------+--------------------------------------+ | status | creating | | share_type_name | dhss_true | | description | None | | availability_zone | None | | share_network_id | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 | | share_server_id | None | | share_group_id | None | | host | | | revert_to_snapshot_support | False | | access_rules_status | active | | snapshot_id | None | | create_share_from_snapshot_support | False | | is_public | False | | task_state | None | | snapshot_support | False | | id | 243f3a51-0624-4bdd-950e-7ed190b53b67 | | size | 1 | | source_share_group_snapshot_member_id | None | | user_id | 61aef4895b0b41619e67ae83fba6defe | | name | software_share | | share_type | 277c1089-127f-426e-9b12-711845991ea1 | | has_replicas | False | | replication_type | None | | created_at | 2018-10-09T21:12:21.000000 | | share_proto | NFS | | mount_snapshot_support | False | | project_id | cadd7139bc3148b8973df097c0911016 | | metadata | {} | +---------------------------------------+--------------------------------------+
View the status of the share:
clouduser1@client:~$ manila list +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+ | ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone | +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+ | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1 | NFS | error | False | dhss_true | | None | +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
In this example, an error occurred during the share creation.
To view the user support message, run the
message-list
command. Use the--resource-id
to filter to the specific share you want to find out about.clouduser1@client:~$ manila message-list +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+ | ID | Resource Type | Resource ID | Action ID | User Message | Detail ID | Created At | +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+ | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001 | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008 | 2018-10-09T21:12:21.000000 | +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
In the
User Message
column, notice that the Shared File Systems service failed to create the share because of a capabilities mismatch.To view more message information, run the
message-show
command, followed by the ID of the message from themessage-list
command:clouduser1@client:~$ manila message-show 7d411c3c-46d9-433f-9e21-c04ca30b209c +---------------+----------------------------------------------------------------------------------------------------------+ | Property | Value | +---------------+----------------------------------------------------------------------------------------------------------+ | request_id | req-0a875292-6c52-458b-87d4-1f945556feac | | detail_id | 008 | | expires_at | 2018-11-08T21:12:21.000000 | | resource_id | 243f3a51-0624-4bdd-950e-7ed190b53b67 | | user_message | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | | created_at | 2018-10-09T21:12:21.000000 | | message_level | ERROR | | id | 7d411c3c-46d9-433f-9e21-c04ca30b209c | | resource_type | SHARE | | action_id | 001 | +---------------+----------------------------------------------------------------------------------------------------------+
As the cloud user, you can check capabilities through the share type so you can review the share types available. The difference between the two share types is the value of
driver_handles_share_servers
:clouduser1@client:~$ manila type-list +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+ | ID | Name | visibility | is_default | required_extra_specs | optional_extra_specs | Description | +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+ | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 | dhss_false | public | YES | driver_handles_share_servers : False | create_share_from_snapshot_support : True | None | | | | | | | mount_snapshot_support : False | | | | | | | | revert_to_snapshot_support : False | | | | | | | | snapshot_support : True | | | 277c1089-127f-426e-9b12-711845991ea1 | dhss_true | public | - | driver_handles_share_servers : True | create_share_from_snapshot_support : True | None | | | | | | | mount_snapshot_support : False | | | | | | | | revert_to_snapshot_support : False | | | | | | | | snapshot_support : True | | +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
Create a share with the other available share type:
clouduser1@client:~$ manila create nfs 1 --name software_share --share-network mynet --share-type dhss_false +---------------------------------------+--------------------------------------+ | Property | Value | +---------------------------------------+--------------------------------------+ | status | creating | | share_type_name | dhss_false | | description | None | | availability_zone | None | | share_network_id | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 | | share_group_id | None | | revert_to_snapshot_support | False | | access_rules_status | active | | snapshot_id | None | | create_share_from_snapshot_support | True | | is_public | False | | task_state | None | | snapshot_support | True | | id | 2d03d480-7cba-4122-ac9d-edc59c8df698 | | size | 1 | | source_share_group_snapshot_member_id | None | | user_id | 5c7bdb6eb0504d54a619acf8375c08ce | | name | software_share | | share_type | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 | | has_replicas | False | | replication_type | None | | created_at | 2018-10-09T21:24:40.000000 | | share_proto | NFS | | mount_snapshot_support | False | | project_id | cadd7139bc3148b8973df097c0911016 | | metadata | {} | +---------------------------------------+--------------------------------------+
In this example, the second share creation attempt fails.
View the user support message:
clouduser1@client:~$ manila list +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+ | ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone | +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+ | 2d03d480-7cba-4122-ac9d-edc59c8df698 | software_share | 1 | NFS | error | False | dhss_false | | nova | | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1 | NFS | error | False | dhss_true | | None | +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+ clouduser1@client:~$ manila message-list +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+ | ID | Resource Type | Resource ID | Action ID | User Message | Detail ID | Created At | +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+ | ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 | SHARE | 2d03d480-7cba-4122-ac9d-edc59c8df698 | 002 | create: Driver does not expect share-network to be provided with current configuration. | 003 | 2018-10-09T21:24:40.000000 | | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001 | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008 | 2018-10-09T21:12:21.000000 | +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
The service does not expect a share network for the share type that you used.
Without consulting the administrator, you can discover that the administrator has not made available a storage back end that supports exporting shares directly on to your private neutron network. Create the share without the
share-network
parameter:clouduser1@client:~$ manila create nfs 1 --name software_share --share-type dhss_false +---------------------------------------+--------------------------------------+ | Property | Value | +---------------------------------------+--------------------------------------+ | status | creating | | share_type_name | dhss_false | | description | None | | availability_zone | None | | share_network_id | None | | share_group_id | None | | revert_to_snapshot_support | False | | access_rules_status | active | | snapshot_id | None | | create_share_from_snapshot_support | True | | is_public | False | | task_state | None | | snapshot_support | True | | id | 4d3d7fcf-5fb7-4209-90eb-9e064659f46d | | size | 1 | | source_share_group_snapshot_member_id | None | | user_id | 5c7bdb6eb0504d54a619acf8375c08ce | | name | software_share | | share_type | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 | | has_replicas | False | | replication_type | None | | created_at | 2018-10-09T21:25:40.000000 | | share_proto | NFS | | mount_snapshot_support | False | | project_id | cadd7139bc3148b8973df097c0911016 | | metadata | {} | +---------------------------------------+--------------------------------------+
Ensure that the share was created successfully:
clouduser1@client:~$ manila list +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+ | ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone | +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+ | 4d3d7fcf-5fb7-4209-90eb-9e064659f46d | software_share | 1 | NFS | available | False | dhss_false | | nova | | 2d03d480-7cba-4122-ac9d-edc59c8df698 | software_share | 1 | NFS | error | False | dhss_false | | nova | | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1 | NFS | error | False | dhss_true | | None | +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
Delete the shares and support messages:
clouduser1@client:~$ manila message-list +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+ | ID | Resource Type | Resource ID | Action ID | User Message | Detail ID | Created At | +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+ | ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 | SHARE | 2d03d480-7cba-4122-ac9d-edc59c8df698 | 002 | create: Driver does not expect share-network to be provided with current configuration. | 003 | 2018-10-09T21:24:40.000000 | | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001 | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008 | 2018-10-09T21:12:21.000000 | +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+ clouduser1@client:~$ manila delete 2d03d480-7cba-4122-ac9d-edc59c8df698 243f3a51-0624-4bdd-950e-7ed190b53b67 clouduser1@client:~$ manila message-delete ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 7d411c3c-46d9-433f-9e21-c04ca30b209c clouduser1@client:~$ manila message-list +----+---------------+-------------+-----------+--------------+-----------+------------+ | ID | Resource Type | Resource ID | Action ID | User Message | Detail ID | Created At | +----+---------------+-------------+-----------+--------------+-----------+------------+ +----+---------------+-------------+-----------+--------------+-----------+------------+
6.12.2. Debugging share mounting failures
If you experience an issue when you mount shares, use these verification steps to identify the root cause.
Procedure
Verify the access control list of the share to ensure that the rule that corresponds to your client is correct and has been successfully applied.
$ manila access-list share-01
In a successful rule, the
state
attribute equalsactive
.If the share type parameter is configured to
driver_handles_share_servers=False
, copy the hostname or IP address from the export location and ping it to confirm connectivity to the NAS server:$ ping -c 1 172.17.5.13 PING 172.17.5.13 (172.17.5.13) 56(84) bytes of data. 64 bytes from 172.17.5.13: icmp_seq=1 ttl=64 time=0.048 ms--- 172.17.5.13 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 7.851/7.851/7.851/0.000 ms If using the NFS protocol, you may verify that the NFS server is ready to respond to NFS rpcs on the proper port: $ rpcinfo -T tcp -a 172.17.5.13.8.1 100003 4 program 100003 version 4 ready and waiting
NoteThe IP address is written in universal address format (uaddr), which adds two extra octets (8.1) to represent the NFS service port, 2049.
If these verification steps fail, there might be a network connectivity issue, or your shared file system back-end storage has failed. Collect the logs and contact Red Hat Support.