VMware vSphere Virtual Volumes (vVOLs) was one of the new features that were added back in the vSphere 6.0 release. Recently with vSphere 6.5, a few enhancements were made to the vVOLs and I am seeing quite a few customers use this in their production environment.
On my day to day conversation with customers, mostly the SysAdmins, I realized that there is still some misconceptions about vVOLs. Hence, I decided to write this post after referring to multiple sources and figured will share with a larger audience.
Firstly, VMware Virtual Volumes are not like your traditional VMFS datastores and quite different in the way they work. VMware vSphere Virtual volumes are encapsulations of virtual machine files, virtual disks, and their derivatives.
VMware vSphere Virtual Volumes map virtual disks and their respective components directly to objects, called virtual volumes, on a storage system.
Virtual volumes are not pre-provisioned but created automatically when you perform virtual machine management operations like VM creation, cloning, and snapshot, hence allowing vSphere to offload these operations directly to the storage system.
Another important thing to note is vVOL is not a feature that vSphere delivers, like vMotion, etc., but an API that storage vendors must implement.
What are the requirements for VMware vSphere Virtual Volumes?
Software
- vCenter Server 6.0 Appliance (VCSA) or vCenter Server 6.0 for Windows
- ESXi 6.0
- vSphere Web Client
Hardware
- Any Server that is certified for vSphere 6.0 that is listed on the VMware compatibility guide.
- A third party storage array system that supports VMware vSphere Virtual Volumes and able to integrate with vSphere through the VMware APIs for Storage Awareness.
License
- vCenter Server Standard
- ESXi Enterprise Plus
Why should I use VMware vSphere Virtual Volumes?
Following are the benefits that one can get when using Virtual Volumes compared to legacy storage technologies:
- Automation of storage “class-of-service” at scale: Provision virtual machines quickly across data center using a common control plane (SPBM) for automation.
- Self-Service capabilities: Empower application administrators with cloud automation tool integration (vRealize Automation, PowerCLI, OpenStack).
- Simple change management using policies: Eliminate change management overhead and use policies to drive infrastructure changes.
- Finer control of storage class of service: Match VM storage requirements exactly as needed with a class of service delivered per VM.
- Effective monitoring/troubleshooting with per VM visibility: Gain visibility on individual VM performance and storage consumption.
- Non-disruptive transition: Use existing protocols (Fiber channel, ISCSI, NFS) across heterogeneous storage devices.
- Safeguard existing investment: Use existing resources more efficiently with an operational model that eliminates inefficient static and rigid storage constructs.
What are the different types of Virtual Volumes Objects?
As discussed earlier, Virtual Volumes are a new type of virtual machine objects, which are created and stored natively on the storage array.
vVOLs are stored in storage containers and mapped to virtual machine files/objects such as VM swap, VMDKs, and their derivatives.
There are five different types of Virtual Volumes object types and each of them maps to a different and specific virtual machine file.
- Config – VM Home, Configuration files, logs
- Data – Equivalent to a VMDK
- Memory – Snapshots
- SWAP – Virtual machine memory swap
- Other – vSphere solution specific object
What are the components of VMware vSphere Virtual Volumes?
There are four major components when it comes to the implementing Virtual Volumes which are:
- Protocol Endpoint (PE)
- Storage Container (SC)
- Vendor Provider (VASA)
- Virtual Datastore
Protocol Endpoints (PE)
Protocol endpoints are the access points from the hosts to the storage systems, which are created by storage administrators. A PE represents the IO access point for a Virtual Volume.
When a Virtual Volume is created, it is not immediately accessible for IO. To Access Virtual Volumes, vSphere needs to issue a “Bind” operation to a VASA Provider (VP), which creates IO access point for a Virtual Volume on a PE chosen by a VP. A single PE can be the IO access point for multiple Virtual Volumes. “Unbind” Operation will remove this IO access point for a given Virtual Volume.
Protocol Endpoints are part of the physical storage fabric, they inherit the access functionalities of today's LUNs and thereby can support all industry standard protocols.
Protocol Endpoints are compatible with all SAN/NAS industry standard protocols:
- iSCSI
- NFS v3
- Fiber Channel (FC)
- Fiber Channel over Ethernet (FCoE)
A Protocol Endpoint can support any one of the protocols at a given time. Existing multi-path policies and NFS topology requirements can be applied to the PE.
Storage Containers (SC)
Virtual Volumes reside in storage containers. Storage Containers are logical storage constructs that are defined and setup by storage administrators. These containers are used to define:
- Storage capacity allocations and restrictions
- Storage policy settings based on data service capabilities on a per virtual machine basis
There needs to be at least one Storage Container on the storage array. More SCs can be created on the design and implementation process.
A storage Container is made accessible to an ESXi host and has a 1:1 relationship with storage containers created on the storage array. For example, if you create three storage containers on the array you will then have three corresponding VVol datastores available to the connecting hosts.
Also, note that multiple Protocol Endpoints can access the Storage containers simultaneously. The Storage containers are discovered and made available to vSphere using the VASA provider which is our next component.
VASA Provider / Vendor Provider (VP)
Vendor Providers (VP), also referred to as VASA Provider, is a storage-side software component (Plug-In) that act as a storage awareness service for vSphere. Storage vendors exclusively develop vendor providers.
Vendor provider is implemented through VMware APIs for Storage Awareness (VASA) and is used to manage all aspects of VVols storage.
Vendor provider delivers information from the underlying storage, so that storage container capabilities can appear in vCenter Server and the vSphere Web Client.
Vendor Providers are typically setup and configured by the vSphere administrator in one of two ways:
- Automatically via the array vendors plug-in
- Manually through the vCenter Server
Virtual Datastore
A Virtual Datastore represents a storage container in a vCenter Server instance and the vSphere Web Client. A vSphere Virtual Datastore represents a one-to one mapping to the storage system’s storage container.
The storage container (or Virtual Datastore) represents a logical pool where individual Virtual Volumes created VMDKs are created.
The VVols datastore is similar to any other datastore and is used to hold virtual machines. Like other datastores, the VVols datastore can be browsed and lists configuration virtual volumes by virtual machine name.
I hope this has been informative and thank you for reading!
Reference Articles:
