How-To
How To Create VMware Virtual Volumes
VVOLs, as they're known, could revolutionize your datacenter. Learn how they work and how to set them up.
At the VMware Partner Exchange (PEX) in February, VMware announced vSphere 6.0. vSphere was an evolutionary release for VMware, with one major exception: It included Virtual Volumes (VVOLs), a revolutionary new feature.
VVOLs are revolutionary in the way they allow virtual machines (VMs) to consume storage. No longer do LUNs and shares need to have attributes such as performance and protection levels assigned to them, then have VMs assigned to the LUNs to use the attributes. VVOLs allow the capabilities or attributes of the underlying attached storage to be surfaced up to vSphere; VMs can have storage provisioned for them based on capabilities, rather than being indirectly based on the LUN or share.
Virtual Volumes Mechanics
VVOLs allow a layer of abstraction and control between the hypervisor and storage. VVOLs separate a storage's data plane from the storage's control plane. Protocol Endpoints (PEs) are used by the data plane to transfer data between the hypervisor and storage. vSphere APIs for Storage Awareness (VASA) 2.0 is used by the control plane.
PEs allow data to flow from the hypervisor to the storage array in a non-protocol-specific manner; no longer do you need to set up mounts for NAS or targets for SAN storage on vSphere. The first generation of VASA (VASA 1) only allowed unidirectional communication from vSphere to the storage array, whereas VASA 2 allows bidirectional communication from/to vSphere and its attached storage. By allowing bidirectional communication, the storage can surface attributes (also known as storage capabilities) from the storage back to vSphere.
On the array, the storage administrator carves out pools of storage into storage containers (SCs) that have attributes such as performance, replication, encryption and protection. Once a PE has been attached to vSphere, the SCs are used to create a VVOL datastore; a storage policy can then be created based on the SC attributes. An SC can have more than one policy attached to it.
Each policy has one or more rulesets created from the SC attributes that will be used to meet the requirements of a VM. When a VM is created a storage policy is selected; all the datastores that can meet the requirements are displayed, and one can be selected for use. Often, during the life of a VM the storage requirements will change, and to accommodate these changes the VM can be reassigned a storage policy.
When the VM is created, the array passes the attributes the VM needs; it's up to the array to meet these requirements. This can be thought of as a new layer of abstraction for vSphere and the underlying storage. Figure 1 is a diagram that Hitachi put together that explains the relationships between the VVOL components.
[Click on image for larger view.]
Figure 1. The relationships between Virtual Volumes components. Courtesy of Hitachi.
Virtual Volumes, Step by Step
Each storage provider will have its own idiosyncrasies around the way it incorporates VVOLs, but they all follow these basic steps:
-
Create storage container on storage array. This will vary depending on the vendor.
-
Select the attributes to be surfaced from the array. This will vary depending on the vendor.
-
Register the storage provider with vSphere. Accomplished through vCenter.
-
Create datastores from storage container. Done through vCenter.
-
Create Storage Policies. Done through vCenter.
-
Deploy VMs to VVOLs. Done through vCenter.
-
Manage storage lifecycle of the VM. Done through vCenter and the underlying storage.
As vSphere has yet to GA, I collected the information here from news briefs, videos, taking VMware hands-on labs and discussing VVOLs with various people. As vSphere 6, which includes support for VVOLs, hasn't officially been released, the information in this article may differ some.
The creation of a storage container will vary depending on the specific vendor. The number of SCs per array will tend to be small (usually less than a couple dozen), and vendors will have specific limits on the number of SCs supported on their arrays. On the vSphere side, currently there's a limit of 256 SCs per host. Figure 2, provided by Dell, shows how a storage container is created on an array.
[Click on image for larger view.]
Figure 2. Creating a storage container on an array. Courtesy of Dell.
Attributes for an SC can be surfaced on vSphere either individually or as a group. Figure 3 shows how NexGen storage bundles many put attributes together to be presented to vSphere as a single object.
[Click on image for larger view.]
Figure 3. A storage container's attributes. Courtesy of NexGen.
Each storage provider will have a different mechanism to instantiate the array's PE. The PE establishes the data plane for the array to transfer data to and from the ESXi hosts. vSphere must be made aware of the storage provider; this is done via the vCenter Web portal under the Storage Providers tab. A URL, user name and a password are required to establish the connection.
PEs are compatible with both NAS and SAN devices. They replace the concept of LUNs and mount points. An array can have multiple PEs, and every PE can be used to access all the storage containers and VVOLs on an array. Like a LUN or mount point, multiple hosts and even hosts in different clusters can access a PE. Multipathing is supported with PEs, but the multipathing plug-ins will need to be modified. Figure 4 shows the vCenter dialog for adding a new storage provider and establishing a PE connection.
[Click on image for larger view.]
Figure 4. Adding a storage provider for VVOLs.
VVOL datastores are added (see Figure 5) in the same manner as a VMFS or NFS datastore.
[Click on image for larger view.]
Figure 5. Creating a Virtual Volumes datastore.
Once the SC has been presented to vSphere, the attributes of the SC can be used to create a storage profile. VMware presents capabilities common to all storage (for example, thin or thick provisioning), which can be selected via the Common Capabilities dropdown menu. Rules can also be built up from vendor-specific capacities. These capabilities are presented via checkbox, radio buttons and text boxes. The SC capabilities can be bundled together as a group or presented individually; vendors have wide leniency in how they present their array's capabilities.
Each policy can have multiple rulesets, and these rulesets can come from different vendors. This allows the administrator to choose from any SC that meets their storage policy goals. Figure 6 shows how Hitachi presents its capabilities for selection. It has a novel attribute of a cost label.
[Click on image for larger view.]
Figure 6. Creating a ruleset for a Hitachi storage array.
Courtesy of Hitachi.
Different attributes can be created using the same SC, which can greatly optimize the use cases for a particular storage array. No longer do LUNs or shares need to be created with specific attributes that meet the requirements of the VM. The attributes of the VM's policy are passed back to the storage, and the array implements them on a per-VM basis.
NetApp, for example, can present a pre-defined profile to vSphere and present the attributes as a single selection to create a ruleset. This is shown in Figure 7.
[Click on image for larger view.]
Figure 7. Creating a ruleset specific to NetApp. Courtesy of NetApp.
The workflow to create VVOL-based VMs is similar to deploying them on traditional storage, except that a storage policy is selected in place of a traditional datastore. The storage policy then displays the datastores that are compatible and incompatible with the policy.
Each VM will initially have at least three VVOLs associated with it: config, data (one per VMDK) and swap. Each VM snapshot will add one VVOL per virtual disk; if a memory snapshot is specified, another VVOL will be created.
VVOLs allow snapshots, clones and other storage-specific operations to be offloaded to the array rather than having vSphere complete them. Depending on the storage vendor's implementation of VVOLs, this can reduce the time needed to perform the operation and reduce the amount of storage used.
With the initial release of VVOLs, some features like storage DRS (SDRS) aren't supported.
Figure 8 shows a VM using the VM-SQL-ProdDB storage policy. Once selected, the VVOL datastore (Platinum) compatible with the storage policy is displayed.
[Click on image for larger view.]
Figure 8. A virtual machine showing which datastores do and don't work with the policy.
A datastore can have a default storage policy associated with it. If storage policies aren't used and a VVOL datastore is used, the VM will have the default storage policy. A datastore's default can easily be changed, as shown in Figure 9.
[Click on image for larger view.]
Figure 9. Setting the default storage policy on a NexGen datastore. Courtesy of NexGen.
During a VM's lifecycle, its storage requirement may change; it may need a more performant back-end storage or to be better protected. A VM's storage policy can be changed while the VM is active; the array will opportunistically modify it to meet the new policy's attributes.
VMs created on a non-VVOL datastore can be moved (via Storage vMotion) to a VVOL datastore without incurring an outage.
With the introduction of VVOLs, VMware has not only changed the way storage is consumed by VMs; it's radically changed the modern datacenter.
VVOLs greatly simplifies the consumption of storage. No longer do we need to have storage portioned out with the attributes desired: Now, the system administrator is given a block of storage that can be consumed efficiently on a per-VM basis. No longer do we need to dedicate valuable enterprise storage for a specific purpose: Now, the storage administrator simply allocates a hunk of storage for use. No longer do we need to worry about whether storage is NAS- or SAN-based: Through the use of protocol endpoints, VVOLs introduces a layer of abstraction above this from vSphere to the storage. No longer do we need to concern ourselves with the management, time and space consumed by snapshots and clones: The array will do it in the most efficient way possible.
Your Datacenter Will Never Be the Same
VVOLs storage policies will change the way we do business in the datacenter. Datacenters are data-centric, and VVOLs storage policies can surface not only primary storage attributes, but can also be used to surface secondary attributes such as backup policies. Each vendor can leverage their unique capabilities. For example, backups need not be a separate feature tied to an obscure function; it can be tied directly to the storage on a VM's inception.
The VVOLs feature has been a long time coming, but I predict it will be rapidly embraced by the storage community and the datacenter, and will be further enhanced by VMware. VMware is dead serious about getting VVOLs in the datacenter as soon as possible by including it with all editions of vSphere. Companies such as Dell are including VVOLs functionality at no charge in its arrays, which should also speed VVOLs adoption in datacenters, no matter the size.