--- title: "VAST Driver for Cinder" slug: "vast-driver-for-cinder" updated: 2026-11-04T20:06:33Z published: 2026-11-04T20:06:33Z canonical: "docs.vastdata.com/vast-driver-for-cinder" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt > Use this file to discover all available pages before exploring further. # VAST Driver for Cinder VAST Driver for Cinder enables you to use VAST NVMe storage as a backend for data volumes managed through the OpenStack Block Storage service (Cinder). The VAST driver for Cinder supports volume operations shown in [Supported Operations and Usage Examples](/develop/docs/vast-driver-for-cinder#supported-operations-and-usage-examples). To deploy the VAST driver for Cinder, complete these steps: - Ensure that [prerequisites](/develop/docs/vast-driver-for-cinder#prerequisites) are met. - [Set up](/develop/docs/vast-driver-for-cinder#set-up-the-openstack-host) the OpenStack host. - [Configure](/develop/docs/vast-driver-for-cinder#configure-vast-cluster-for-cinder) the VAST cluster so that Cinder can use it as the backend. - [Configure](/develop/docs/vast-driver-for-cinder#configure-cinder-to-use-vast-backend) Cinder to use the VAST cluster as the backend. If you encounter any issues, refer to the troubleshooting guidelines in [Troubleshooting](/develop/docs/vast-driver-for-cinder#troubleshooting). ## Prerequisites Support for block storage (NVMe over TCP) has been introduced in VAST release 5.3. Your VAST cluster must be running VAST release 5.3 or later so that it allows configuring VAST Element Store views that support the block access protocol. ## Set up the OpenStack Host - **Networking**: Ensure that your OpenStack has access to the access network (e.g., the Web UI address) and the data network (e.g., protocol virtual IP pool address) of the VAST cluster. - **Permissions**: - root or sudo permissions on the OpenStack host - admin permission to the OpenStack Web UI (Horizon) - Install **NVMe CLI**: ```plaintext sudo yum install nvme-cli ``` - Load kernel modules required to enable NVMe over Fabrics: ```plaintext sudo modprobe nvme sudo modprobe nvme-fabrics ``` ## Configure VAST Cluster for Cinder > [!NOTE] > **Note** > > The VAST cluster must be running release 5.3 or later to support block access. Complete the following steps to make your VAST cluster ready for integration with Kubernetes: 1. **Create a tenant** for Cinder block volumes. VAST strongly recommends creating a new tenant dedicated to storing Cinder volumes. Since the VAST driver requires a VMS manager account to automate provisioning via API calls, it is highly recommended to isolate this account from being able to impact data and configuration that might otherwise exist on the same tenant. Even if every other use case on the cluster is using the default tenant, creating a Cinder-dedicated tenant is strongly recommended. 2. Under the tenant created in [step 1](/develop/docs/vast-driver-for-cinder), **create a view** that will expose the NVMe subsystem for Cinder. The view must have the block storage protocol enabled (Protocols = *Block*) and an NVMe subsystem defined. To view and manage views in VAST Web UI, log in and choose Element Store -> Views in the main navigation menu. For more information about VAST Cluster views, see *VAST Cluster Administrator's Guide*. 3. Ensure that the cluster provides a **virtual IP pool** to be used by the VAST driver. You can create a new virtual IP pool or use an existing one. The virtual IP pool must be explicitly associated with the same tenant (created in [step 1](/develop/docs/vast-driver-for-cinder)) as the NVMe subsystem (block view) created in [step 2](/develop/docs/vast-driver-for-cinder). Since you'll have to specify the virtual IP pool by its name, ensure that the VAST cluster has DNS configured, and the virtual IP pool has *Virtual IP Pool Domain Name* defined in its settings. To view and manage virtual IP pools in VAST Web UI, log in and choose Network Access -> Virtual IP Pools in the main navigation menu. For more information about VAST Cluster virtual IP pools, see *VAST Cluster Administrator's Guide*. 4. **Create a role** to be assigned to a service account (VMS manager user that you'll create in [step 5](/develop/docs/vast-driver-for-cinder)) the VAST driver will use to communicate with VMS. The role must be created in the tenant dedicated to storing Cinder volumes. The role must grant the Create, View, Edit and Delete permissions in the Logical realm. To view and manage VMS manager roles in VAST Web UI, log in and choose Administrators -> Roles in the main navigation menu. 5. **Create a VMS manager user** to be used by the VAST driver to communicate with the VAST Management Service (VMS) via VAST REST API. You'll need to supply, in the Cinder configuration file, the VMS user credentials (username and password) or VMS API token generated for that user. **NOTE**: Using VMS authentication tokens is recommended over supplying VMS user credentials. While the VAST driver can use the `admin` account, it is strongly recommended to create a dedicated VMS manager user account for the driver. This account must be assigned a role associated with the tenant that will store the Cinder volumes. **Assign the role** created in [step 4](/develop/docs/vast-driver-for-cinder) to the VMS manager user. To view and manage VMS manager users in VAST Web UI, log in and choose Administrators -> Managers in the main navigation menu. To generate and manage VMS API tokens for a VMS manager user, run the VAST CLI's `apitoken *` commands. For more information about managing VMS manager users, see *VAST Cluster Administrator's Guide*. ## Configure Cinder to Use VAST Backend 1. Edit the Cinder configuration file (`/etc/cinder/cinder.conf`) as follows: - In the `[DEFAULT]` section, specify a name for the new backend on the `enabled_backends` parameter. Below the name `vast` is specified: ```plaintext [DEFAULT] enabled_backends = vast ``` If the parameter lists multiple backends, separate the values with commas. - Create a new backend section for the newly enabled backend (`vast`) and specify the following options: ```plaintext [vast]       volume_driver = volume_backend_name = san_ip = [san_api_port = ] {  san_login =  san_password =  |  vast_api_token =  } vast_vippool_name = vast_subsystem = ``` Where: - `volume_driver` sets the driver path. Specify it as `cinder.volume.drivers.vastdata.driver.VASTVolumeDriver`. - `volume_backend_name` sets the backend name (e.g. `vast`). - `san_ip` sets the IP address of the VAST Management Service (VMS) running on the VAST cluster. - `san_api_port` specifies the port where the VMS is listening. This parameter is optional. If not specified, port 443 is used. - `san_login` is the user name of the [VMS manager user](/develop/docs/vast-driver-for-cinder) that the driver will use to communicate with the VAST cluster's VMS. By default, the `admin` user is used. This parameter is only required if no VMS API token is supplied. If you have `vast_api_token` specified, this parameter is ignored. - `san_password` is the VMS manager user password. This parameter is only required if no VMS API token is supplied. If you have `vast_api_token` specified, this parameter is ignored. - `vast_api_token` specifies the VMS API token used to authenticate and authorize driver access to the VAST cluster. This parameter is required if no VMS manager credentials are supplied. - `vast_vippool_name` specifies the name of the virtual IP pool [configured](/develop/docs/en/vast-driver-for-cinder) for block storage on the VAST cluster. - `vast_subsystem` is the name of the NVMe subsystem [exposed](/develop/docs/vast-driver-for-cinder) by the VAST cluster. For example: ```plaintext [vast] volume_driver = cinder.volume.drivers.vastdata.driver.VASTVolumeDriver volume_backend_name = vast san_ip = 10.27.200.136 san_login = admin san_password = 123456 vast_vippool_name = vip-pool1 vast_subsystem = cinder-test ``` 2. Restart the Cinder service to apply configuration changes: ```plaintext systemctl restart openstack-cinder-*.service ``` ## Supported Operations and Usage Examples The driver supports the following operations: - Create, list, delete volumes - Attach (map) and detach (unmap) volumes - Create, list, delete volume snapshots - Restore a volume from a snapshot - Clone a volume - Extend a volume For example: - To create a new volume type named `vast`: ```plaintext openstack volume type create vast ``` - To create a volume named `vast-vol` of type `vast`: ```plaintext openstack volume create --size 100 --type vast vast-vol ``` - To attach volume `1234abcd-5678-90ef-1234-567890abcdef` to instance `a1b2c3d4-e5f6-7890-abcd-ef1234567890`: ```plaintext openstack server add volume ``` - To extend volume `9f8e7d6c-5b4a-3210-fedc-ba9876543210`: ```plaintext openstack volume set --size 200 9f8e7d6c-5b4a-3210-fedc-ba9876543210 ``` - To view details of volume `1234abcd-5678-90ef-1234-567890abcdef`: ```plaintext openstack volume show 1234abcd-5678-90ef-1234-567890abcdef ``` - To create a snapshot named `test-snapshot` of volume `1234abcd-5678-90ef-1234-567890abcdef`: ```plaintext openstack volume snapshot create --volume 1234abcd-5678-90ef-1234-567890abcdef test-snapshot ``` - To delete snapshot `test-snapshot`: ```plaintext openstack volume snapshot delete test-snapshot ``` - To set volume `1234abcd-5678-90ef-1234-567890abcdef` to *Active* state: ```plaintext openstack volume set --state available abcdef12-3456-7890-abcd-ef1234567890 ``` > [!NOTE] > **Note** > > Perform this operation only when the volume is in a bad state and no actions can be performed on it. ## Troubleshooting Cinder logs are saved under `/var/log/cinder/` but not all actions are logged under `cinder`. Disk attach/detach operations are performed by the OpenStack Compute Service (Nova). it is recommended to start troubleshooting with `/var/log/cinder/volume.log`. When hitting volumes attachments issues, investigate `/var/log/nova/nova-compute.log`. - **volume.log** captures information related to the core volume operations. It records events such as volume creation, deletion, attaching/detaching volumes to instances, and any errors encountered during these operations. This log is critical for troubleshooting volume-related issues, such as slow volume creation, failed volume operations, and issues with specific storage drivers. - **api.log** captures information related to the Cinder API service. It records requests received by the API, responses sent to clients, and any exceptions or errors encountered during API processing. This log is crucial for debugging API-related issues, such as invalid requests, authentication problems, and authorization errors. - **backup.log** specifically tracks activities related to volume backups. It records backup requests, their progress, successful completions, and any failures encountered during the backup process. This log is essential for troubleshooting backup issues, such as failed backups, slow backup performance, and issues with specific backup drivers. - **cinder-manage.log** captures output from the `cinder-manage` command-line tool. The `cinder-manage` tool is used for various administrative tasks, such as database upgrades, volume migrations, and running checks on the Cinder service. This log provides valuable insights into the execution of these administrative tasks, including any errors or warnings encountered. - scheduler.log records the activities of the Cinder scheduler. The scheduler is responsible for selecting the appropriate backend (e.g. storage driver) to host a newly created volume. This log tracks the scheduling decisions made by the scheduler, including the criteria used for selecting backends, any scheduling failures, and any conflicts encountered during the scheduling process.