Recently, Virtual Volumes (VVOLs) are often on speakers, bloggers's lips. So I decided to write this post which covers some Virtual Volumes features and answers for the following questions:
- What are Virtual Volumes (VVOL)?
- Why Virtual Volumes (VVOL) are really useful?
- What are Storage Container and Protocol Endpoint?
- What is Policy Based Management?
- VVOL requirements and support by Storage Vendors?
Understanding Virtual Volumes (VVOLs)
Virtual Volumes (VVOLs) is a new feature addition with vSphere 6.0 and provides a new abstraction to control a storage and makes SAN/NAS devices aware of individual VM or VMDK files. VMware defines Virtual Volumes as below:
Virtual Volumes is a storage management and integration framework with SAN/NAS arrays that exposes virtual disks as native storage containers and enables array-based operations at the virtual disk granular level.
Currently all storage is LUN-centric or volume-centric, especially when it comes to snapshots, clones and replication. VVols makes storage VM-centric. With VVols, most of the data operations can be offloaded to the SAN/NAS devices and Virtual volumes are not preprovisioned, but created automatically when you perform virtual machine management operations. So what kind of VVOLs are created during VM management? There are VVOLS as follows:
- 1 VVol for VM config which represents a small directory that contains metadata files for a virtual machine. The files include a .vmx file, descriptor files for virtual disks, log files, and so forth.
- 1 VVol for every virtual disk (.VMDK)
- 1 VVol for swap, if needed
- 1 VVol per disk snapshot and 1 per memory snapshot
So for example, a VM with 3 virtual disks would have 1+3+1=5 Virtual Volumes. Taking snapshots of VM would add 3+1=4 Virtual Volumes.
Using VVOLs, the storage array doesn't have to process and maintain connection logins as it does currently for each LUN (max 256 LUNs per hosts). All storage request is done over one connection (Protocol Endpoint).
vSphere Virtual Volumes Architecture
vSphere Virtual Volumes Architecture
There are main Virtual Volumes (VVOLs) components as follow:
- Vendor Provider (VASA ver 2.0) – management of data operations (providing policy-based management)
- Storage Container (SC) (represented in vCenter via VVOLs datastore) – management of data capacity
- Protocol Endpoints (PE) – management of access control and communications
Storage policies are bases on VASA 2.0. The control path and data path are logically separated.
Storage Admin defines storage containers (size, capabilities) on the storage side (at least one container for each storage system is required). vSphere Admin creates a VVOLs datastore on the vSphere side.
After the storage capabilities are discovered by the vCenter Server, policies (Storage Policy-Based Management (SPBM)) can be created based on application performance, data protection, business continuity, and security requirements. The VASA management plane will perform compatibility checks against the underlying VVol container, and only present compatible container(s) for placement if all capabilities from the policy are satisfied.
Storage Container (SC)
Storage Container (SC) is a piece of physical storage where VVOLs are grouped. SC is typically associated with a capacity and a set of capabilities.
Storage Container is represented in vCenter via VVOLs Datastore:
The created VVols datastore points directly to the specific Storage Container (SC) and has the following functionalities:
- Browse and list configuration virtual volumes by virtual machine name.
- Support unmounting and mounting.
As described above, VVOLs datastores are similar to VMFS/NFS datastores.
There is a limit of 256 Storage Containers per host but when would you have more? For example, if you would have more than 256 SAN/NAS devices connected to ESXi host 🙂 I have never seen such configuration 😉
Protocol Endpoint (PE)
Protocol Endpoint (PE) are used to connect to the virtual disks in a VVOL datastore by ESXi hosts. They are intended to replace the concept of LUNs (FC/iSCSI) and mount points (NFS). It means that Storage Admins do not need to configure LUNs or NFS exports. It is just necessary to configure Protocol Endpoint (PE) for a specific type of access, create Storage Containers (SCs) based on groupings of required capabilities and physical storage. Then the VMware admins can create VVols in these SCs via vCenter/ESXi hosts.
VVOLs requirements
There are two main requirements to use VVOLs:
- The array vendor supports VVOLs.
- The vendor provides VASA. If you do not what VASA is, please follow my another post here.
Virtual Volumes (VVOL) are supported by some storage vendors such NetApp, HP, EMC or Nimble Storage(Compatibility Guide). For example, NetApp supports VVOLs since Clustered Data ONTAP 8.2.1. Sometimes vendors requires additional softwares to be installed to support VVOLs. NetApp requires not only VASA provider but also Virtual Storage Console (VSC).
Of course, VMware Virtual SAN (VSAN) is also supported on VVOL datastore 🙂
VVOL limitations
Currently, there are following limitations:
-
Storage DRS (SDRS) is not supported with VVOLs.
-
SCSI-2 reservations are not supported.
Virtual Volumes (VVLs) are a long-awaited vSphere feature, at last available with vSphere 6!
There are some posts with VVOLs in practice: