VNX Driver

EMC manila driver framework (EMCShareDriver) utilizes the EMC storage products to provide the shared filesystems to OpenStack. The EMC manila driver is a plugin based driver which is designed to use different plugins to manage different EMC storage products.

VNX plugin is the plugin which manages the VNX to provide shared filesystems. EMC driver framework with VNX plugin is referred to as VNX driver in this document.

This driver performs the operations on VNX by XMLAPI and the File command line. Each backend manages one Data Mover of VNX. Multiple manila backends need to be configured to manage multiple Data Movers.

Note

Dell EMC VNX driver has been deprecated and will be removed in a future release

Requirements

• VNX OE for File version 7.1 or higher.

• VNX Unified, File only, or Gateway system with single storage backend.

• The following licenses should be activated on VNX for File: * CIFS * NFS * SnapSure (for snapshot) * ReplicationV2 (for create share from snapshot)

Supported Operations

The following operations will be supported on VNX array:

• Create CIFS/NFS Share

• Delete CIFS/NFS Share

• Allow CIFS/NFS Share access * Only IP access type is supported for NFS. * Only user access type is supported for CIFS.

• Deny CIFS/NFS Share access

• Create snapshot

• Delete snapshot

• Create share from snapshot

While the generic driver creates shared filesystems based on Cinder volumes attached to Nova VMs, the VNX driver performs similar operations using the Data Movers on the array.

Pre-Configurations on VNX

1. Enable Unicode on Data mover

VNX driver requires that the Unicode is enabled on Data Mover.

CAUTION: After enabling Unicode, you cannot disable it. If there are some filesystems created before Unicode is enabled on the VNX, consult the storage administrator before enabling Unicode.

To check the Unicode status on Data Mover, use the following VNX File command on VNX control station:

server_cifs <mover_name> | head where: mover_name = <name of the Data Mover>

Check the value of I18N mode field. UNICODE mode is shown as I18N mode = UNICODE

To enable the Unicode for Data Mover:

uc_config -on -mover <mover_name> where: mover_name = <name of the Data Mover>

Refer to the document Using International Character Sets on VNX for File on [EMC support site](https://support.emc.com) for more information.

2. Enable CIFS service on Data Mover

Ensure the CIFS service is enabled on the Data Mover which is going to be managed by VNX driver.

To start the CIFS service, use the following command:

server_setup <mover_name> -Protocol cifs -option start [=<n>] where: <mover_name> = <name of the Data Mover> [=<n>] = <number of threads for CIFS users>

Note: If there is 1 GB of memory on the Data Mover, the default is 96 threads; however, if there is over 1 GB of memory, the default number of threads is 256.

To check the CIFS service status, use this command:

server_cifs <mover_name> | head where: <mover_name> = <name of the Data Mover>

The command output will show the number of CIFS threads started.

3. NTP settings on Data Mover

VNX driver only supports CIFS share creation with share network which has an Active Directory security-service associated.

Creating CIFS share requires that the time on the Data Mover is in sync with the Active Directory domain so that the CIFS server can join the domain. Otherwise, the domain join will fail when creating share with this security service. There is a limitation that the time of the domains used by security-services even for different tenants and different share networks should be in sync. Time difference should be less than 10 minutes.

It is recommended to set the NTP server to the same public NTP server on both the Data Mover and domains used in security services to ensure the time is in sync everywhere.

Check the date and time on Data Mover:

server_date <mover_name> where: mover_name = <name of the Data Mover>

Set the NTP server for Data Mover:

server_date <mover_name> timesvc start ntp <host> [<host> …] where: mover_name = <name of the Data Mover> host = <IP address of the time server host>

Note: The host must be running the NTP protocol. Only 4 host entries are allowed.

4. Configure User Mapping on the Data Mover

Before creating CIFS share using VNX driver, you must select a method of mapping Windows SIDs to UIDs and GIDs. EMC recommends using usermapper in single protocol (CIFS) environment which is enabled on VNX by default.

To check usermapper status, use this command syntax:

server_usermapper <movername> where: <movername> = <name of the Data Mover>

If usermapper is not started, the following command can be used to start the usermapper:

server_usermapper <movername> -enable where: <movername> = <name of the Data Mover>

For multiple protocol environment, refer to Configuring VNX User Mapping on [EMC support site](https://support.emc.com) for additional information.

5. Network Connection

In the current release, the share created by VNX driver uses the first network device (physical port on NIC) of Data Mover to access the network.

Go to Unisphere to check the device list: Settings -> Network -> Settings for File (Unified system only) -> Device.

Backend Configuration

The following parameters need to be configured in /etc/manila/manila.conf for the VNX driver:

emc_share_backend = vnx emc_nas_server = <IP address> emc_nas_password = <password> emc_nas_login = <user> emc_nas_server_container = <Data Mover name> emc_nas_pool_name = <pool name> emc_interface_ports = <Comma separated ports list> share_driver = manila.share.drivers.dell_emc.driver.EMCShareDriver driver_handles_share_servers = True

• emc_share_backend is the plugin name. Set it to vnx for the VNX driver.

• emc_nas_server is the control station IP address of the VNX system to be managed.

• emc_nas_password and emc_nas_login fields are used to provide credentials to the VNX system. Only local users of VNX File is supported.

• emc_nas_server_container field is the name of the Data Mover to serve the share service.

• emc_nas_pool_name is the pool name user wants to create volume from. The pools can be created using Unisphere for VNX.

• emc_interface_ports is comma separated list specifying the ports(devices) of Data Mover that can be used for share server interface. Members of the list can be Unix-style glob expressions (supports Unix shell-style wildcards). This list is optional. In the absence of this option, any of the ports on the Data Mover can be used.

• driver_handles_share_servers must be True, the driver will choose a port from port list which configured in emc_interface_ports.

Restart of manila-share service is needed for the configuration changes to take effect.

IPv6 support

IPv6 support for VNX driver is introduced in Queens release. The feature is divided into two parts:

1. The driver is able to manage share or snapshot in the Neutron IPv6 network.

2. The driver is able to connect VNX management interface using its IPv6 address.

Pre-Configurations for IPv6 support

The following parameters need to be configured in /etc/manila/manila.conf for the VNX driver:

network_plugin_ipv6_enabled = True

• network_plugin_ipv6_enabled indicates IPv6 is enabled.

If you want to connect VNX using IPv6 address, you should configure IPv6 address by nas_cs command for VNX and specify the address in /etc/manila/manila.conf:

emc_nas_server = <IPv6 address>

Snapshot support

In the Mitaka and Newton release of OpenStack, Snapshot support is enabled by default for a newly created share type. Starting with the Ocata release, the snapshot_support extra spec must be set to True in order to allow snapshots for a share type. If the ‘snapshot_support’ extra_spec is omitted or if it is set to False, users would not be able to create snapshots on shares of this share type. The feature is divided into two parts:

1. The driver is able to create/delete snapshot of share.

2. The driver is able to create share from snapshot.

Pre-Configurations for Snapshot support

The following extra specifications need to be configured with share type.

• snapshot_support = True

• create_share_from_snapshot_support = True

For new share type, these extra specifications can be set directly when creating share type:

manila type-create --snapshot_support True --create_share_from_snapshot_support True ${share_type_name} True

Or you can update already existing share type with command:

manila type-key ${share_type_name} set snapshot_support=True
manila type-key ${share_type_name} set create_share_from_snapshot_support=True

To snapshot a share and create share from the snapshot

Firstly, you need create a share from share type that has extra specifications(snapshot_support=True, create_share_from_snapshot_support=True). Then snapshot the share with command:

manila snapshot-create ${source_share_name} --name ${target_snapshot_name} --description " "

After creating the snapshot from previous step, you can create share from that snapshot. Use command:

manila create nfs 1 --name ${target_share_name} --metadata source=snapshot --description " " --snapshot-id ${source_snapshot_id}

Restrictions

The VNX driver has the following restrictions:

• Only IP access type is supported for NFS.

• Only user access type is supported for CIFS.

• Only FLAT network and VLAN network are supported.

• VLAN network is supported with limitations. The Neutron subnets in different VLANs that are used to create share networks cannot have overlapped address spaces. Otherwise, VNX may have a problem to communicate with the hosts in the VLANs. To create shares for different VLANs with same subnet address, use different Data Movers.

• The ‘Active Directory’ security service is the only supported security service type and it is required to create CIFS shares.

• Only one security service can be configured for each share network.

• Active Directory domain name of the ‘active_directory’ security service should be unique even for different tenants.

• The time on Data Mover and the Active Directory domains used in security services should be in sync (time difference should be less than 10 minutes). It is recommended to use same NTP server on both the Data Mover and Active Directory domains.

• On VNX the snapshot is stored in the SavVols. VNX system allows the space used by SavVol to be created and extended until the sum of the space consumed by all SavVols on the system exceeds the default 20% of the total space available on the system. If the 20% threshold value is reached, an alert will be generated on VNX. Continuing to create snapshot will cause the old snapshot to be inactivated (and the snapshot data to be abandoned). The limit percentage value can be changed manually by storage administrator based on the storage needs. Administrator is recommended to configure the notification on the SavVol usage. Refer to Using VNX SnapSure document on [EMC support site](https://support.emc.com) for more information.

• VNX has limitations on the overall numbers of Virtual Data Movers, filesystems, shares, checkpoints, and etc. Virtual Data Mover(VDM) is created by the VNX driver on the VNX to serve as the manila share server. Similarly, filesystem is created, mounted, and exported from the VDM over CIFS or NFS protocol to serve as the manila share. The VNX checkpoint serves as the manila share snapshot. Refer to the NAS Support Matrix document on [EMC support site](https://support.emc.com) for the limitations and configure the quotas accordingly.

The manila.share.drivers.dell_emc.driver Module

EMC specific NAS storage driver. This driver is a pluggable driver that allows specific EMC NAS devices to be plugged-in as the underlying backend. Use the Manila configuration variable “share_backend_name” to specify, which backend plugins to use.

class EMCShareDriver(*args, **kwargs)

Bases: ShareDriver

EMC specific NAS driver. Allows for NFS and CIFS NAS storage usage.

allow_access(context, share, access, share_server=None)

Allow access to the share.

check_for_setup_error()

Check for setup error.

create_share(context, share, share_server=None)

Is called to create share.

create_share_from_snapshot(context, share, snapshot, share_server=None, parent_share=None)

Is called to create share from snapshot.

create_snapshot(context, snapshot, share_server=None)

Is called to create snapshot.

delete_share(context, share, share_server=None)

Is called to remove share.

delete_snapshot(context, snapshot, share_server=None)

Is called to remove snapshot.

deny_access(context, share, access, share_server=None)

Deny access to the share.

do_setup(context)

Any initialization the share driver does while starting.

ensure_share(context, share, share_server=None)

Invoked to sure that share is exported.

extend_share(share, new_size, share_server=None)

Is called to extend share.

get_configured_ip_versions()

“Get allowed IP versions.

The supported versions are returned with list, possible values are: [4], [6], or [4, 6]

Drivers that assert ipv6_implemented = True must override this method. If the returned list includes 4, then shares created by this driver must have an IPv4 export location. If the list includes 6, then shares created by the driver must have an IPv6 export location.

Drivers should check that their storage controller actually has IPv4/IPv6 enabled and configured properly.

get_default_filter_function()

Get the default filter_function string.

Each driver could overwrite the method to return a well-known default string if it is available.

Parameters:

pool – pool name to get the filter or None

Returns:

None

get_network_allocations_number()

Returns number of network allocations for creating VIFs.

get_share_server_network_info(context, share_server, identifier, driver_options)

Obtain network allocations used by share server.

Parameters:

• context – Current context.

• share_server – Share server model.

• identifier – A driver-specific share server identifier

• driver_options – Dictionary of driver options to assist managing the share server

Returns:

A list containing IP addresses allocated in the backend.

Example:

['10.10.10.10', 'fd11::2000', '192.168.10.10']

manage_existing(share, driver_options)

manage an existing share

manage_existing_snapshot(snapshot, driver_options)

manage an existing share snapshot

manage_existing_snapshot_with_server(snapshot, driver_options, share_server=None)

manage an existing share snapshot

manage_existing_with_server(share, driver_options, share_server=None)

manage an existing share

manage_server(context, share_server, identifier, driver_options)

Manage the share server and return compiled back end details.

Parameters:

• context – Current context.

• share_server – Share server model.

• identifier – A driver-specific share server identifier

• driver_options – Dictionary of driver options to assist managing the share server

Returns:

Identifier and dictionary with back end details to be saved in the database.

Example:

'my_new_server_identifier',{'server_name': 'my_old_server'}

revert_to_snapshot(context, snapshot, share_access_rules, snapshot_access_rules, share_server=None)

Reverts a share (in place) to the specified snapshot.

Does not delete the share snapshot. The share and snapshot must both be ‘available’ for the restore to be attempted. The snapshot must be the most recent one taken by Manila; the API layer performs this check so the driver doesn’t have to.

The share must be reverted in place to the contents of the snapshot. Application admins should quiesce or otherwise prepare the application for the shared file system contents to change suddenly.

Parameters:

• context – Current context

• snapshot – The snapshot to be restored

• share_access_rules – List of all access rules for the affected share

• snapshot_access_rules – List of all access rules for the affected snapshot

• share_server – Optional – Share server model or None

shrink_share(share, new_size, share_server=None)

Is called to shrink share.

unmanage(share)

Removes the specified share from Manila management.

Does not delete the underlying backend share.

For most drivers, this will not need to do anything. However, some drivers might use this call as an opportunity to clean up any Manila-specific configuration that they have associated with the backend share.

If provided share cannot be unmanaged, then raise an UnmanageInvalidShare exception, specifying a reason for the failure.

This method is invoked when the share is being unmanaged with a share type that has driver_handles_share_servers extra-spec set to False.

unmanage_server(server_details, security_services=None)

Unmanages the share server.

If a driver supports unmanaging of share servers, the driver must override this method and return successfully.

Parameters:

• server_details – share server backend details.

• security_services – list of security services configured with this share server.

unmanage_snapshot(snapshot)

Removes the specified snapshot from Manila management.

Does not delete the underlying backend share snapshot.

For most drivers, this will not need to do anything. However, some drivers might use this call as an opportunity to clean up any Manila-specific configuration that they have associated with the backend share snapshot.

If provided share snapshot cannot be unmanaged, then raise an UnmanageInvalidShareSnapshot exception, specifying a reason for the failure.

This method is invoked when the snapshot that is being unmanaged belongs to a share that has its share type with driver_handles_share_servers extra-spec set to False.

unmanage_snapshot_with_server(snapshot, share_server=None)

Removes the specified snapshot from Manila management.

Does not delete the underlying backend share snapshot.

For most drivers, this will not need to do anything. However, some drivers might use this call as an opportunity to clean up any Manila-specific configuration that they have associated with the backend share snapshot.

If provided share snapshot cannot be unmanaged, then raise an UnmanageInvalidShareSnapshot exception, specifying a reason for the failure.

This method is invoked when the snapshot that is being unmanaged belongs to a share that has its share type with driver_handles_share_servers extra-spec set to True.

unmanage_with_server(share, share_server=None)

Removes the specified share from Manila management.

Does not delete the underlying backend share.

For most drivers, this will not need to do anything. However, some drivers might use this call as an opportunity to clean up any Manila-specific configuration that they have associated with the backend share.

If provided share cannot be unmanaged, then raise an UnmanageInvalidShare exception, specifying a reason for the failure.

This method is invoked when the share is being unmanaged with a share type that has driver_handles_share_servers extra-spec set to True.

update_access(context, share, access_rules, add_rules, delete_rules, share_server=None)

Update access to the share.

The manila.share.drivers.dell_emc.plugins.vnx.connection Module

VNX backend for the EMC Manila driver.

class VNXStorageConnection(*args, **kwargs)

Bases: StorageConnection

Implements VNX specific functionality for EMC Manila driver.

allow_access(context, share, access, share_server=None)

Allow access to a share.

check_for_setup_error()

Check for setup error.

clear_access(share, share_server, white_list)

connect(emc_share_driver, context)

Connect to VNX NAS server.

create_share(context, share, share_server=None)

Create a share and export it based on protocol used.

create_share_from_snapshot(context, share, snapshot, share_server=None, parent_share=None)

Create a share from a snapshot - clone a snapshot.

create_snapshot(context, snapshot, share_server=None)

Create snapshot from share.

delete_share(context, share, share_server=None)

Delete a share.

delete_snapshot(context, snapshot, share_server=None)

Delete a snapshot.

deny_access(context, share, access, share_server=None)

Deny access to a share.

ensure_share(context, share, share_server=None)

Ensure that the share is exported.

extend_share(share, new_size, share_server=None)

Invoked to extend share.

get_managed_ports()

get_network_allocations_number()

Returns number of network allocations for creating VIFs.

get_pool(share)

Get the pool name of the share.

setup_server(network_info, metadata=None)

Set up and configures share server with given network parameters.

teardown_server(server_details, security_services=None)

Teardown share server.

update_access(context, share, access_rules, add_rules, delete_rules, share_server=None)

Update access rules for given share.

update_share_stats(stats_dict)

Communicate with EMCNASClient to get the stats.