By Bharath Ram, Senior Technical Marketing Engineer, HPE Nimble Storage
VMware vSphere Virtual Volumes (vVols) has been talked about a lot over the years and we are seeing increased adoption rates as well. Albeit the increase in adoption, there are still admins who are hesitant or unaware of the architecture and advantages vVols provide. VMware vVols bring a lot of benefits and we want to highlight and summarize the top 10.
10 – You no longer need RDM
Whether we like it or not RDMs are still being used in many VMware environments. The major reason RDMs are used is for distributed file locking e.g. Microsoft Windows Server Failover Clustering. With vSphere 6.7 this features supported with vVols. WSFC clustering solutions use SCSI-3 Persistent Reservations which enables access for multiple nodes to a device (vVol disk) and simultaneously blocks access for other nodes.
vVols comes up triumphant over RDMs in other areas such as creation, data protection, reclaiming space etc. So there no reason for anyone to use RDMs going forward.
9 – Better granular controls
With vVols you get granularity in managing VM resources. Storage capabilities such as data protection, replication, QoS, data savings etc can now be applied at the VM or VMDK level. This is the essence of vVols, wherein the VM is storage-aware.
8 – Freedom of mobility
With vVols you get rid of the file system relationship with vSphere and ESXi. The vmdk’s are pretty much individual volumes on the array. This enables the ability to move the volumes around. An example of this would be migrating vVol volumes to the cloud.
Here is an example of how you can migrate vVols to the public cloud leveraging HPE Cloud Volumes.
7 – You don’t have to go all in
It’s not all or nothing with vVols, you can easily run it right alongside VMFS or NFS on the same storage array. Because vVols requires no up-front space allocation for it’s Storage Container, you will only be consuming space on your existing array for any VMs that are put on vVol storage. Since vVols is a dynamic storage architecture, whatever free space you have remaining on the array is available to your vVols Storage Container which is purely a logical entity, unlike a VMFS volume which requires up-front space allocation.
You can easily move running VMs from VMFS to vVols using Storage vMotion and back again if needed or create new VMs on vVols. This allows you to go at your own pace and as you move VMs over you can remove VMFS datastores as they are emptied out which provides more available space to your Storage Container. Note that Storage vMotion is the only method to move existing VM’s to vVols and you cannot upgrade VMFS datastores to vVol Storage Containers.
6 – Get your disk space back and stop wasting it
With vVols both space allocation and space reclamation is completely automatic and real-time. No storage is pre-allocated to the Storage Container or Protocol Endpoint, when VM’s are created on vVols storage they are provisioned thin by default. When VMs are deleted or moved space is automatically reclaimed as the array can see VMs as objects and knows which disk blocks they reside on. No more manually running time and resource intensive cli tools, vmkfstools/esxcli to blindly try and reclaim space on the array from deleted or moved VMs. vVols is designed to allow the array to maintain a very thin footprint without pre-allocating space and carving up your array into silos like you do with VMFS and at the same time being able to reclaim space in real-time.
5 – Let the array do the heavy lifting
Storage operations are very resource intensive and a heavy burden on the host. While servers are commonly being deployed as SAN’s these days, a server really wasn’t built specifically to handle storage I/O like a storage array is. VMware recognized this early on which is why they created vSphere APIs for storage such as VAAI to offload resource-intensive storage operations from the host to the storage array. vVols takes this approach to the next level, it shifts the management of storage tasks to vSphere and utilizing policy-based automation storage operations are shifted to the storage array.
So things like thin provisioning and snapshots which can be done either on the vSphere side or the storage array side with VMFS are only done on the storage array side with vVols. How you do these things remains the same in vSphere but when you take a snapshot in the vSphere client you are now taking an array-based snapshot. The VASA specification which defines vVols is basically just a framework and allows the array vendors to implement certain storage functionality, however they want to handle things within the array is up to each vendor. The storage array is a purpose-built I/O engine designed specifically for storage I/O, it can do things faster and more efficiently, why not let it do what it does best and take the burden off the host.
4 – Start using SPBM right now
vSAN users have been enjoying Storage Policy Based Management for quite a while now and with vVols anyone with an external storage array can now use it as well. While Storage Policies have been around for even longer when first introduced in VASA 1.0, they were very basic and not all that useful. The introduction of VASA 2.0 in vSphere 6.0 was a big overhaul for SPBM and made it much more rich and powerful. The benefit of using SPBM is that makes it easier for vSphere and storage admins by automating storage provisioning and mapping storage array capabilities including features and hardware attributes directly to individual VMs. SPBM ensures compliance of defined policies so you can create SLA’s and align storage performance, capacity, availability and security features to meet application requirements.
3 – Snapshots don’t suck anymore
vSphere native VM snapshots have always been useful but they also have a dark side. One of the big disadvantages of vSphere snapshots is the commit process (deleting a snapshot) which can be very time and resource consuming, the more so the longer a snapshot is active. The reason for this is that when you create a vSphere snapshot, the base disk becomes read only and any new writes are deflected to delta vmdk files that are created for each VM snapshot. The longer a snapshot is active and the more writes that are made the larger the delta files grow, if you take multiple snapshots you create more delta files. When you delete a snapshot all those delta files have to be merged back into the base disk which can take a very long time and is resource intensive. As backup agents routinely take snapshots before doing a backup of a VM, snapshots are a pretty common occurrence.
With vVols the whole VM snapshot process changes dramatically, a snapshot taken in vSphere is not performed by vSphere but instead created and managed on the storage array. The process is similar in the fact that separate delta files are still created but the files are vVols snapshots that are array-based and more importantly what happens while they are active is reversed. When a snapshot of a VM on vVol-based storage is initiated in vSphere a delta vVol is created for each virtual disk that a VM has but the original disk remains Read-Write and instead the delta vVols contain any disk blocks that were changed while the snapshot is running. The big change occurs when we delete a snapshot, with vVols because the original disk is Read-Write, we can simply discard the delta vVols and there is no data to commit back into the original disk. This process can take milliseconds compared to minutes or hours that is needed to commit a snapshot on VMFS datastores.
The advantage of vVols array based snapshots are many, they run more efficiently on the storage array and you are not using up any host resources. In addition you are not waiting hours for them to commit, your backups will completed quicker and there is no chance of lost data from long snapshot chains trying to be written back into the base disk.
2 – Easier for IT generalists /one management pane
Because storage array management shifts to vSphere through SPBM, IT generalists don’t really have to be storage admins as well. Once the initial array setup is complete and the necessary vVols components created, all the common provisioning tasks that you would normally do on the array to support vSphere are done through automation. No more creating LUNs, expanding LUNs, configuring thin provisioning, taking array based snapshots, etc., it’s all done automatically. When you create a VM, storage is automatically provisioned on the storage array and there is no more worrying about creating more LUNs, determining LUN sizes and increasing LUN sizes when needed.
With vVols you are only managing VMs and storage in vSphere, not in 2 places. As a result if you don’t have a dedicated storage admin to manage your storage array, an IT generalist or vSphere admin can do it pretty easily. Everything with SPBM is designed to be dynamic and autonomic and it really unifies and simplifies management in a good and efficient manner to reduce the overall burden of storage management in vSphere. Instead of having the added complexity of using vendor specific storage management tools, with vVols management becomes more simplified through the native vSphere interfaces.
The VI admin can leverage the vVol workflows available within the storage vCenter plugin accordingly to the VASA specification. This is where the VI admin can manage storage capabilities and assign them to individual VMs or disks
1 – The VM is now a unit of storage
This is what it’s all about, the LUN is dead, because it’s all about the VM, ’bout the VM, no LUN. With vVols the VM is now a first-class citizen and the storage array has VM-level visibility. Applications and VMs can be directly and more granularly aligned with storage resources. Where VMFS was very LUN-centric and static creating silos within an array, aligning data services to LUNs and utilizing pre-allocated and over-provisioned resources. vVols is VM-centric and dynamic where nothing is pre-allocated, no silos are created and array data services are aligned at the more granular VM-level. This new operational model transforms storage in vSphere to simplify management, deliver better SLAs and provide much improved efficiency. vVols enables application-specific requirements to drive provisioning decisions while leveraging the rich set of capabilities provided by storage arrays.
