So today I will talk about VMware Virtual volumes or vVols. vVols are somewhat confusing sometimes so let’s dig in.
What are VMware Virtual Volumes?
First of all a vVol is nothing like a a traditional VMware datastore (VMDK or NFS). vVols work completely different and are more of an “grouping” of Virtual machine files (disk, swap, etc.)
Secondly vVols are linked (or you could say mapped) directly to the underlaying storage array. These mapped objects on the storage array are called virtual volumes, hence the name vVols.
Another big difference to traditional datastores is that you do not have to create them upfront. They are automatically created when you deploy a VM, clone a VM, create a Snapshot, etc.
vVols are API driven. So the storage array must support this API driven deployment model leveraging the VMware API for Storage Awareness (VASA)
Why vVols?
So now that we know a bit more about vVols but why should you use them? Here are some reasons why to use vVols.
Automation
With vVols you have the ability to quickly provision VM workloads without the need to pick and choice the right storage type. You manage storage by using storage policies that you can assign and use for each VM using the vSphere Storage Policy management framework (SPBM).
Manageability
vVols offer you the option to more granularly manage your individual VM storage. You get the ability to monitor each VM individually. (setting up QoS, monitoring performance, capacity management, etc.)
Storage integration and offload capabilities
With vVols you can leverage the underlaying storage capabilities. For instance to offload snapshots to the storage Array instead of using vSphere based snapshots.
Overcoming traditional datastore shortcomings
Things like LUN count and path limits or creating NFS exports are a thing of the past.
vVols an inside look
vVol objects
Virtual machine files are stored directly on the storage array as virtual machine objects.
We can identify different types of objects:
- Config – Configuration files, log files, lock files
- Swap – Virtual machine memory swap
- Data – Similar to a traditional VMDK
These files reside inside storage containers to form the vVols.
Make up of a vVol
vVol architecture components:
- Storage Containers (SC)
- Protocol Endpoints (PE)
- API vendor integrations (VASA provider or VP)
- vVols
Storage Containers:
Storage containers are a logical storage layer and are created by Storage Administrators. For each container you can define storage characteristics. Characteristics like capacity and restrictions (QoS for instance). These policy settings are set per VM instead of per datastore (the traditional way)
There is a direct relation between a Storage container and the storage array. If you create 2 storage containers on the storage array you will also have 2 vVols available on the ESXi host. Every storage array has at least 1 Storage Container.
Please note that a Storage Container is not a LUN !!
Protocol Endpoints:
Protocol endpoints are a proxy for IO between the vVol datastore and the ESXi host. In other words, they enable communication between the host and the array. PE’s support all standard protocols for example: iSCSI, NFS, FC and FCoE.
Protocol Endpoints are discoverable by ESXi host when performing rescan operations. PE’s are multi-path supported so multi-path policies can be used.
VASA provider:
The VASA provider, or VP, is a piece of software created by the storage vendor. The VP is used to expose the storage array capabilities to the ESXi hosts. In term the ESXi host can then use those capabilities to assign them to a Virtual Machine. The VP uses vSphere API’s and is usually incorporated on the storage controllers or supplies as a virtual appliance.
vVol benefits
Let’s have a look at some of the benefits of vVol’s shall we?
- Policy based; you can easily assign another storage policy without impacting the VM’s
- You can resized (grow and shrink). No need for UNMAP or other storage reclaim processes
- No fixed sizes. You only use what is needed so each VM will consume the exact amount of storage needed.
- Size is based on the array size and not the datastore size.
- Dataservices are offloaded to the array (e.g. snapshots on array instead of VMware snapshots)
- Simplified management for admins.
Requirements to run vVols
Lastly, lets quickly some up what is needed to use vVols
- A storage array that supports vVols and can use VMware API’s for Storage awareness
- vSphere vCenter and ESXi hosts
- A vCenter standard and an ESXi Enterprise Plus license.
So there you have it, VMware Virtual volumes or vVols explained. I hope this information was useful and if you would like to know more about vVol’s have a look here.
If you liked this blog post please check out some of our other posts on vSphere here. Or for example some of our vCloud post here
