Getting Started with the DataCore VASA Provider

In this topic:

About VASA Provider

Getting started

Creating disk pools for storage containers

Creating virtual disk templates to define storage container capabilities

Creating a datastore on a storage container

Creating VM storage policies

Creating virtual machines

Creating snapshots

Migrating and cloning virtual machines

About DataCore VASA Provider

The SANsymphony™ Software-defined Storage platform has been integrated with the virtualization world of VMware vSphere™ datacenter platform and vCenter™ management by providing a DataCore VASA Provider (a set of application programming interfaces that integrates storage arrays with vSphere vCenter and allows the capabilities to be known) that has a vSphere Aware Storage application programming interface (API) for SANsymphony software. The DataCore VASA Provider allows administrators to configure SANsymphony storage resources as storage containers for virtual machines and enables storage policy-based management (SPBM) of virtual machines—all from the VMware vSphere Web Client.

Custom storage policies, based on storage performance characteristics, are created and defined in VMware vSphere Web Client to help Virtual Infrastructure (VI) administrators overcome storage provisioning challenges. The DataCore VASA Provider enables SPBM by advertising the capabilities of the datastores to the vCenter. The administrator selects the desired storage policy and can then choose from a list of compatible storage containers when a virtual machine is deployed. In turn, a SANsymphony VVOL virtual disk is automatically created from compatible pools making the virtual machine hard disk policy compliant, thus extending virtual machine-level management to the storage layer.

Terminology

Storage Container (SC)

A storage container is used to create VVOL datastores (also known as virtual volumes or VVOLs) that are connected to a storage provider.

Storage containers are defined and resourced from SANsymphony disk pools.

See Creating a Datastore on a Storage Container for more information.

Virtual volume (VVOL)

A VVOL datastore allocated from a storage container that will be ultimately used to create a virtual machine. Virtual volumes that are allocated from the same storage container will have the capabilities of that storage container. Virtual disk templates define the capabilities of the VVOL datastore.

Virtual volumes are represented in SANsymphony software as VVOL virtual disks.

Protocol Endpoint (PE)

Protocol endpoints identify the location of the VVOL virtual disks and are used to establish paths for virtual machines. They make available virtual volumes to ESXi hosts and route traffic from ESXi hosts to the appropriate SANsymphony virtual disk.

Protocol endpoints are represented as Protocol Endpoint virtual disks in SANsymphony software. See Creating Disk Pools for Storage Containers for more information.

Bind

Binding is the process by which a virtual volume becomes available to ESXi hosts when the virtual machine is powered on.

This process is equivalent to serving the virtual disks representing a virtual volume to the ESXi host. The virtual volume is "bound" to their protocol endpoint and only when bound are visible to the ESXi host.

The VASA Provider creates all the necessary path connections for the protocol endpoint. See Creating Virtual Machines for more information.

Unbind

Unbinding is the process by which a virtual volume becomes unavailable to ESXi hosts when the virtual machine is powered off.

This process is equivalent to unserving the virtual disk.
  • Before you begin, read the DataCore VASA Provider Release Notes and Installation Guide that contains requirements, setup, and installation instructions and other important information. The release notes can be viewed from the SANsymphony installation package or downloaded from the DataCore download site via the SANsymphony package. This feature may be installed using the SANsymphony installation package.
  • During installation of this feature, the VASA Provider is registered with the designated vCenter. A user account with the VVol Managers role is required to install the VASA Provider and perform all actions in VMware vSphere Web Client that involve the VASA Provider, see Registering Users and Assigning Roles for more information.
  • This topic contains information pertaining to the VASA Provider used with the VMware vSphere Web Client and the interactions between vSphere and SANsymphony software, but does not provide instructions for performing vSphere operations. See VMware documentation for information and instructions on performing operations in vSphere, such as creating datastores, storage policies, and virtual machines.
  • Virtual disks that represent VVOLs and Protocol Endpoints are identified by subtypes in SANsymphony software. The subtypes are identified in the Type column in Virtual Disk Lists in the SANsymphony Management Console. The subtype, if applicable, will follow the virtual disk type, for example Single Protocol Endpoint, Mirrored VVOL.
  • Virtual disks in SANsymphony that are associated with virtual machines in VMware vSphere cannot be deleted, renamed, or altered (by commands such as Replace, Move, Split and Unserve, Convert to Mirrored, Convert to Dual, or resizing the virtual disk) in SANsymphony.
  • Paths cannot be changed on a protocol endpoint when a VVOL virtual disk is bound to it.
  • Continuous Data Protection (CDP) and Sequential Storage (Random Write Accelerator) are not supported with VVOLs. Replication is not supported and is not recognized at the VMware level.
  • VVOL virtual disks may be replicated in SANsymphony provided that the user performing the action is an owner of the VVOL virtual disk. Replication is not recognized or make aware of in the vCenter. VVOLs and Site Recovery Manager (SRM) do not inter-operate at the VWware level.
  • All snapshot operations should be performed in the VMware vSphere Web Client. See Creating Snapshots of Virtual Machines for more information.
  • Cloning and migration of virtual machines should be performed in the VMware vSphere Web Client. See Migrating and Cloning Virtual Machines for more information.
  • If the VASA Provider is unavailable for any reason, no configuration changes can be performed with regards to protocol endpoints or VVOL virtual disks. If a virtual machine is powered off, it cannot be powered on when the VASA Provider is unavailable. For these reasons, a best practice is to have the VASA Provider configured for high availability.

Getting Started

Step Procedure

1

The Storage Provider tab in the vSphere Web Client displays information about the DataCore VASA Provider that is used to provision and manage SANsymphony storage resources.

To access the Storage Provider tab:

  • In the VMware vSphere Client or Web Client, from the Home tab, click Hosts and Clusters.
  • In the Navigator, select the vCenter.
  • In the Configure tab, click Storage Providers.

DataCore SANsymphony Provider should be listed as a Storage Provider. The status should be Online. The server group should be in Active mode.

2

In SANsymphony, create disk pools to use as storage containers. See Creating Disk Pools for Storage Containers.

3

In SANsymphony, create virtual disk templates that use the disk pools as storage resources. Templates define the capabilities of the datastores and advertise those capabilities to the vCenter. See Creating Virtual Disk Templates.

4

In the vSphere Web Client, create VVOL datastores on storage containers. Datastores are used to create virtual machines. See Creating a Datastore on a Storage Container.

5

In the vSphere Web Client, use the properties defined in the virtual disk templates to create virtual machine storage policies that match the capabilities of the storage containers (datastores). See Creating VM Storage Policies

6

In the vSphere Web Client, create virtual machines with compatible virtual machine storage policies from a compatible storage container. See Creating Virtual Machines.

Creating Disk Pools for Storage Containers

SANsymphony disk pools are used as storage resources for storage containers. VVOL datastores are created from storage containers.

To create disk pools:

  • See Creating Disk Pools for instructions. Follow the instructions in the wizard to create the required disk pools. Existing disk pools may also be used.
  • Templates define the pools to use when creating VVOL datastores, One disk pool is required to create a datastore without high availability (single VVOL virtual disk), one shared pool is required to create a shared datastore (dual VVOL virtual disk), and two disk pools on different servers are required to create a highly available datastore (mirrored VVOL virtual disk).
  • Multiple VVOL datastores can be created from the same storage resource (pool).

After disk pools are created, create virtual disk templates in order to advertise the capabilities of the datastore to the vCenter.

Interactions in SANsymphony

  • New disk pools are added to the server group configuration under the associated DataCore Server and a Disk Pool Details page is created for each disk pool.

Creating Virtual Disk Templates

Virtual disk templates are used by the VASA Provider to define the capabilities of storage containers which will be used to create VVOL datastores. During the creation of a VVOL datastore in the vSphere Client, all SANsymphony virtual disks templates are listed to assist the administrator in selecting a compatible datastore for the virtual machine. Templates allow for greater control over how virtual machines are provisioned.

Templates replace pool naming conventions used in earlier versions and are now required for the VASA Provider.

Create virtual disk templates in SANsymphony that specify the disk pools that were created as storage containers. Templates can also specify other properties of the VVOL virtual disks that are created as a result of the datastores. Supported features enabled on the virtual disk template will be enabled on the associated virtual disks when the virtual machine is created.

The virtual disk properties defined in a template can then be used to define storage policies (SPBM) for virtual machines in vCenter. See Creating VM Storage Policies.

To create virtual disk templates:

  • See Virtual Disk Templates for more information about templates and instructions to create them.
  • Create templates to describe the capabilities of each pool. More than one template can be created for the same pool.
  • All virtual disk templates created in SANsymphony are eligible, but not required to be used as storage containers in vSphere. All templates will be visible in vSphere regardless of whether they are used in vSphere.

Interactions in SANsymphony

  • A Virtual Disk Template details page is created for each template. The template is added to the Templates list.
  • The DataCore VASA Provider creates protocol endpoint virtual disks (PEs) in SANsymphony for all virtual disk templates.
    • For each template, a pair of protocol endpoints is created: an endpoint for virtual machines and an endpoint for snapshots.
    • Each protocol endpoint is only created once for a specific pool combination, regardless of how many templates use this combination.
    • Protocol endpoints are named with GUIDs. The description of a protocol endpoint starts with "Protocol Endpoint", and includes the virtual disk template name for which this protocol endpoint was created. Several templates can share the same protocol endpoint if they use the same pool combination.
    • Pools and protocol endpoint virtual disks used in templates cannot be removed from the server group configuration.

Creating a Datastore on a Storage Container

From vSphere, create a datastore of type VVOL on a storage container.

Virtual disk templates define the capabilities of a datastore. When a datastore is created, it inherits all storage-based policies from the virtual disk template.

A storage container is the equivalent of a single disk pool (used to create single or dual VVOL virtual disks) or a set of two disk pools (for mirrored VVOL virtual disks).

Virtual volumes created from a particular datastore (storage container) will inherit the capabilities of that storage container. The VASA Provider uses templates to advertise the capabilities of the datastores to the vCenter, and the vCenter uses this information to determine storage container compatibility when a virtual machine is created.

  • In order to create data stores, SANsymphony disk pools and templates defining the capabilities of the datastore are required.
  • Select VVOL as the datastore type when creating the datastore in the wizard.
  • In the container selection in the wizard, virtual disk templates created in SANsymphony will appear in the list of storage containers. Select a virtual disk template that defines a compatible storage container for the datastore.
  • Multiple VVOL datastores can be created from the same storage container.
  • In the event that a storage container becomes noncompliant with the defined storage policy, the existing virtual machines will continue to run in the same storage container with a compliance status of Noncompliant. The virtual machine may be migrated to a compliant storage container.
  • For additional information or instructions on creating storage containers and datastores, refer to VMware documentation.

Interactions in SANsymphony

After the datastore is created:

  • The ESXi hosts selected to use the datastore are automatically registered in SANsymphony if they do not already exist.
  • The corresponding protocol endpoint virtual disks in SANsymphony are served to the selected hosts, either when the datastore is created or after by manually mounting the datastore. (The virtual volume is not available to ESXi hosts until the virtual machine is powered on.)
  • The template selected for the datastore will automatically be set to read-only, prohibiting any changes to the template. Read-only templates can be viewed in the Templates List. The read-only designation is indicated under the icon in the Virtual Disk Template details page.

Creating VM Storage Policies

Storage policies in vSphere are a collection of rules used to specify storage requirements for virtual machines. Storage policy-based management (SPBM) helps administrators choose policy-compliant storage for virtual machines based on application requirements.

The virtual disk properties defined in templates can be used to define virtual machine storage policies in vCenter. After creating a new datastore, the administrator can create a storage policy based on the virtual disk template that matches the datastore.

Possible rules for virtual machine storage policies:

  • Storage profiles
  • Disk type (Single, Mirrored, or Dual)
    • Dual disks require a qualified shared pool in SANsymphony that is configured as the storage container pool
  • Select Enable rules for “DataCore.SANsymphonyV2” storage for Datastore specific rules in the Create VM Storage Policy wizard.
  • Ensure that the datastores that satisfy the rules are displayed as compatible datastores in the Storage Compatibility list in the wizard.
  • The VMware default storage policy selected when deploying a virtual machine will create a virtual machine without high availability (single VVOL virtual disk with a Normal storage profile in SANsymphony software).

For additional information or instructions on creating storage policies, refer to VMware documentation.

Creating Virtual Machines

When creating a virtual machine, the administrator selects a storage policy and the wizard displays a list of compatible datastores to select as storage. This ensures that storage can be selected based on storage policy and the virtual volume is created from a storage container with matching capabilities. As a result, SANsymphony creates a VVOL virtual disk from pools with compatible capabilities and then binds these virtual disks to the virtual machine.

  • To create a compliant virtual machine, select the appropriate storage policy in the wizard and select a datastore from the compatible storage list to create the virtual machine.
  • The VMware default storage policy selected when deploying a virtual machine will create a virtual machine without high availability (a single VVOL virtual disk with a Normal storage profile in SANsymphony software).
  • In the event that a storage container becomes noncompliant with the defined storage policy, the existing virtual machines will continue to run in the same storage container with a compliance status of Noncompliant. The virtual machine may be migrated to a compliant storage container.
  • VVOL virtual disks created by the VASA provider use system managed mirroring by default.

Interactions in SANsymphony

When a virtual machine is created:

  • Typically there are three associated virtual disks created in SANsymphony: one for configuration data, one for the virtual machine hard disk (vmdk file), and one for swap data (vswp file). These virtual disks are named with GUIDs, and the name of the virtual machine appears in the description. For any additional hard drive, an additional virtual disk is created.

    Do not delete any virtual disks associated with a virtual volume in VMware.

    • The vmdk and configuration file for the virtual volume will appear in the configuration during the virtual machine creation.
    • The swap file will appear in the configuration when the virtual machine is powered on and disappears from the configuration when the virtual machine is powered off.
    • When the virtual machine is turned on, the virtual volume is bound to the protocol endpoint, and the virtual machine hard disk (vmdk) is made available to hosts. The virtual machine hard disk is displayed in the Hosts panel under the ESXi hosts and under the associated protocol endpoint. Since the virtual disks are not served to the hosts, there will be no serve information or front-end paths displayed in the SANsymphony Management Console. Only mirror paths are displayed. Hosts only see protocol endpoints, which directs and connects the virtual machine to the corresponding virtual volume. I/O goes directly to the virtual volume.
  • Supported features enabled on the virtual disk template will be enabled on the virtual disks when the virtual machine is created.
  • Mirrored or dual VVOL virtual disks, by default, use a special type of virtual disk for mirroring. Mirrored disks are visible in the server group configuration and appear as a single 4 KB virtual disk on each server that has a storage source in mirrored or dual VVOL virtual disks. The base name for a mirrored disk is "Mirror Trunk" and a number is appended to make the name unique in the server group. Mirrored virtual disks are named Mirror Trunk 1, Mirror Trunk 2 and so on. They have a virtual disk type of Single Trunk.

For additional information or instructions on creating virtual machines, refer to VMware documentation.

Creating Snapshots of Virtual Machines

  • Snapshot operations should be performed in the VMware vSphere Web Client. Snapshots of VVOL virtual disks cannot be created directly from SANsymphony software.
  • Snapshot virtual disks will be created and maintained in SANsymphony as a result of snapshot operations performed in the vSphere Web Client. They will be placed in the pool and node specified by the Preferred Snapshot Pool of the virtual disk template. If no preferred snapshot pool is selected in the template, the VASA Provider will use the pool that is specified first in the virtual disk template.
  • In SANsymphony, snapshots will be named with GUIDs, and the virtual machine name will appear in the description. Snapshots of VVOL virtual disks will appear in the console and have the subtype VVOL.
  • Do not perform any snapshot operations on existing snapshots of VVOL virtual disks or manipulate the snapshots in any way from SANsymphony software.
  • If a mapstore pool is not assigned in SANsymphony, the VASA provider will automatically set it to be the pool where the first snapshot of a virtual volume is created.

Migrating and Cloning Virtual Machines

  • Cloning and migration of virtual machines should be performed in the VMware vSphere Web Client, not in SANsymphony software.
  • Migrations can be performed to change the virtual machine storage, change the host, or both. For example, the storage may be changed if it becomes incompatible over time, or to change the policy of a virtual machine from a single VVOL virtual disk (not highly available) to a mirrored VVOL virtual disk (highly available).
  • When a virtual machine does not differ much from the snapshot, cloning is faster than doing block level copies of the virtual machine.
  • During migration or cloning, it is possible that many snapshots, DataCore Disks, and pass-through virtual disks may be created in SANsymphony software to facilitate the process. These entities may or may not be automatically removed after the operation is completed.

    These entities are owned by the VASA Provider and ESX and therefore should not be manipulated in any way.