Vastdata Share Driver

VAST Share Driver integrates OpenStack with VAST Data’s Storage System. Shares in the Shared File System service are mapped to directories on VAST, and are accessed via NFS protocol using a Virtual IP Pool.

Supported shared filesystems

The driver supports NFS shares.

Operations supported

The driver supports NFS shares.

The following operations are supported:

  • Create a share.

  • Delete a share.

  • Allow share access.

  • Deny share access.

  • Extend a share.

  • Shrink a share.

Requirements

  • The Trash Folder Access functionality must be enabled on the VAST cluster.

Driver options

All configuration options for this driver are documented in the Configuration Reference.

VAST Share Driver configuration example

The following example shows parameters in the manila.conf file that are used to configure VAST Share Driver. They include two options under [DEFAULT] and parameters under [vast]. Note that a real manila.conf file would also include other parameters that are not specific to VAST Share Driver.

Note

The vast_vippool_name parameter can be omitted from manila.conf if you plan to specify different VIP pools per share type using the vast:vippool_name extra spec. See the Multitenancy support section for more details.

[DEFAULT]
enabled_share_backends = vast
enabled_share_protocols = NFS

[vast]
share_driver = manila.share.drivers.vastdata.driver.VASTShareDriver
share_backend_name = vast
driver_handles_share_servers = False
snapshot_support = True
vast_mgmt_host = {vms_ip}
vast_mgmt_port = {vms_port}
vast_mgmt_user = {mgmt_user}
vast_mgmt_password = {mgmt_password}
vast_api_token = {vast_api_token}
vast_vippool_name = {vip_pool}
vast_root_export = {root_export}

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

Pre-configurations for share support

To create a file share, you need to:

Create the share type:

openstack share type create ${share_type_name} False \
    --extra-specs share_backend_name=${share_backend_name}

Create an NFS share:

openstack share create NFS ${size} --name ${share_name} --share-type ${share_type_name}

Multitenancy support via Share Types

The VAST Share Driver supports multitenancy by allowing different share types to use different VIP pools. This enables tenant isolation and provides flexibility in network configuration.

VIP Pool Configuration

The VIP pool can be specified in two ways:

  1. Global default in manila.conf using vast_vippool_name

  2. Per share type using the vast:vippool_name extra spec

When both are specified, the share type extra spec takes precedence over the configuration file setting.

Creating Share Types with Different VIP Pools

You can create multiple share types, each using a different VIP pool for multitenancy:

# Tenant A with dedicated VIP pool
openstack share type create vast-tenant-a false \
    --extra-specs share_backend_name=vast \
    --extra-specs vast:vippool_name=vippool-tenant-a

# Tenant B with dedicated VIP pool
openstack share type create vast-tenant-b false \
    --extra-specs share_backend_name=vast \
    --extra-specs vast:vippool_name=vippool-tenant-b

Creating Shares with Specific VIP Pools

When creating a share, specify the share type to determine which VIP pool will be used:

# Create a share for Tenant A (uses vippool-tenant-a)
openstack share create NFS 100 \
    --name tenant-a-share \
    --share-type vast-tenant-a

# Create a share for Tenant B (uses vippool-tenant-b)
openstack share create NFS 50 \
    --name tenant-b-share \
    --share-type vast-tenant-b

This approach enables:

  • Network isolation between different tenants or projects

  • Service differentiation with different network configurations per tenant or environment

  • Flexible deployment without modifying manila.conf

Note

If vast_vippool_name is not specified in manila.conf and a share is created without a share type that specifies vast:vippool_name, the share creation will fail with an error indicating that a VIP pool must be specified.

Pre-Configurations for Snapshot support

The share type must have the following parameter specified:

  • snapshot_support = True

You can specify it when creating a new share type:

openstack share type create ${share_type_name} false \
    --snapshot-support=true \
    --extra-specs share_backend_name=${share_backend_name}

Or you can add it to an existing share type:

openstack share type set ${share_type_name} --extra-specs snapshot_support=True

To snapshot a share and create share from the snapshot

Create a share using a share type with snapshot_support=True. Then, create a snapshot of the share using the command:

openstack share snapshot create ${source_share_name} --name ${target_snapshot_name}

The manila.share.drivers.vastdata.driver Module

VAST’s Share Driver

Configuration:

[DEFAULT] enabled_share_backends = vast

[vast] share_driver = manila.share.drivers.vastdata.driver.VASTShareDriver share_backend_name = vast snapshot_support = true driver_handles_share_servers = false vast_mgmt_host = v11 vast_vippool_name = vippool-1 vast_root_export = manila vast_mgmt_user = admin vast_mgmt_password = 123456

class VASTShareDriver(*args, **kwargs)

Bases: ShareDriver

Driver for the VastData Filesystem.

Version history:

1.0 - Initial version.
      - Support for NFS shares.
      - Support for snapshots (create, delete, revert).
      - Support for share creation from snapshots.
      - Support for share access rules (IP-based).
      - Support for share resize (extend/shrink).
1.1 - Added multi-tenancy support.
      - Support for per-share VIP pool selection via extra specs.
VERSION = '1.1'
create_share(context, share, share_server=None)

Is called to create share.

Parameters:

  • context – The request context.

  • share – The share model. When the share belongs to a share group, the model may include a share_group_members key containing a list of all share instances currently in the group. Drivers can use this to maintain backend group-level constructs (e.g. a consistency group) when a new member is added.

  • share_server – The share server model or None.

create_snapshot(context, snapshot, share_server=None)

Is called to create a snapshot.

delete_share(context, share, share_server=None)

Called to delete a share

delete_snapshot(context, snapshot, share_server=None)

Is called to remove share.

do_setup(context)

Driver initialization

ensure_shares(context, shares)

Invoked to ensure that shares are exported.

Driver can use this method to update the “status” and/or list of export locations of the shares if they change. To do that, a dictionary of shares should be returned. In addition, the driver can seek to “reapply_access_rules” (boolean) on a per-share basis. When this property exists and is set to True, the share manager service will invoke “update_access” with all the access rules from the service database. :shares: A list of all shares for updates. :returns: None or a dictionary of updates in the format.

Example:

{
    '09960614-8574-4e03-89cf-7cf267b0bd08': {
        'export_locations': [{...}, {...}],
        'status': 'error',
        'reapply_access_rules': False,
    },

    '28f6eabb-4342-486a-a7f4-45688f0c0295': {
        'export_locations': [{...}, {...}],
        'status': 'available',
        'reapply_access_rules': True,
    },

}
extend_share(share, new_size, share_server=None)

uses resize_share to extend a share

get_backend_info(context)

Get driver and array configuration parameters.

Driver can use this method to get the special configuration info and return for assessment. The share manager service uses this assessment to invoke “ensure_shares” during service startup.

Returns:

A dictionary containing driver-specific info.

Example:

{
     'version': '2.23'
     'port': '80',
     'logicalportip': '1.1.1.1',
      ...
}

get_network_allocations_number()

Returns number of network allocations for creating VIFs.

Drivers that use Nova for share servers should return zero (0) here same as Generic driver does. Because Nova will handle network resources allocation. Drivers that handle networking itself should calculate it according to their own requirements. It can have 1+ network interfaces.

shrink_share(share, new_size, share_server=None)

uses resize_share to shrink a share

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

Update access rules for share.

policy_payload_from_rules(rules, policy, action)

Convert list of manila rules

into vast compatible payload for updating/creating policy.

validate_access_rule(access_rule)