The Virtual Volumes feature of vSphere provides a means of virtualizing, provisioning and consuming storage within...
the enterprise, while promising better storage flexibility, granularity and management to the virtual machine level. Let's take a closer look at virtual volumes and consider some of the issues involved.
What are the components of a Virtual Volumes environment?
VMware describes the architecture of vSphere Virtual Volumes (VVOLs) as four unique elements: the VVOLs themselves, storage containers, VASA provider plug-ins and protocol endpoints. Let's look at each element and see how they relate.
VSphere VVOLs are the basic units of this virtualization technology which represent up to five different object types that are created and stored on a physical storage subsystem. Config-VVOL objects are used to hold configuration files and logs. Memory-VVOL objects hold snapshots of VM content. Data-VVOL objects are used for VM file storage such as virtual machine disk files and Swap-VVOL objects are used to hold memory swap content -- similar to page files. Finally, Other-VVOL objects are left intentionally undefined to serve as generic storage objects.
All virtual volume objects are stored within storage containers, which are nothing more than logical entities that define storage capacity allocation with access and policy settings -- the VMware equivalent of traditional LUNs. Storage containers are presented to vSphere as virtual datastores. Administrators typically use storage containers as a way to group related VVOL objects that use similar policies or services.
The architecture of vSphere VVOLs also requires a way for ESXi hosts and vCenter Server to recognize storage subsystem capabilities like topology, capacity, features, status and so on. This requires plug-ins from the storage vendors, and each plug-in must adhere to the vSphere API for Storage Awareness (VASA) version 2.0 or later. These plug-ins are collectively called VASA providers or vendor providers. Based on the storage capabilities revealed by each plug-in, storage administrators can develop policies through storage policy-based management (SPBM).
And finally, there must be a mechanism for VMs to exchange data with the virtual volume objects stored on physical storage arrays. VSphere employs protocol endpoints which provide the transport between ESXi hosts and storage subsystems. Protocol endpoints can connect to many VVOLs, allowing the entire VVOL architecture to scale better than traditional LUN-based storage. Protocol endpoints support iSCSI, NFS v3, Fibre Channel and FCoE protocols.
In order for VVOL technology to work, both VMware and storage array vendors must provide a series of interoperating components. For example, vSphere 6.0 or later users will need to enable vSphere VVOLs, vSphere SPBM and VASA. The storage array subsystems must support VMware's VASA API 2.0 or later and supply VASA provider (i.e., vendor provider) plug-ins for ESXi hosts and vCenter Server. Older storage arrays may not be compatible with vSPhere VVOLs, or a firmware upgrade may be needed in order to support VVOL technology.
What you need to know when implementing vSphere VVOLs
Can storage arrays take advantage of vSphere VVOLs?
How do Virtual Volumes compare to VM-aware storage?
How VMware VVOLs will change storage products
Dig Deeper on Selecting storage and hardware for VMware environments
Related Q&A from Stephen J. Bigelow
Regression tests and UAT ensure software quality and both require a sizeable investment. Learn when and how to perform each one, and some tips to get... Continue Reading
Learn the meaning of functional vs. nonfunctional requirements in software engineering, with helpful examples. Then, see how to write both and build ... Continue Reading
Just because software passes functional tests doesn't mean it works. Dig into stress, load, endurance and other performance tests, and their ... Continue Reading