VMware introduced Virtual Volumes (VVOLS) at VMworld 2011 during a technical preview session. After a long gestation...
period, VVOLS has appeared in public beta and is set for release in the next version of vSphere. VMware VVOLs generated a lot of buzz because it presents a radical change to how VMs are stored and managed.
So what is a VVOL?
To fully understand what a VVOL is and the impact it will have, let's look at how storage is provisioned today. In the physical world, we carve a LUN on our physical storage array, ensuring we meet storage requirements such as feature set -- deduplication, compression, etc. -- and RAID level -- 1, 5, 6, etc. -- and present that LUN to a physical machine. The system attached to that LUN is the only system accessing that LUN at any time.
When we introduced virtualization, the concepts didn't change much. We would still go to the storage team to provision a LUN. However, this time we would format that LUN as a VMFS data store and place several VMs on that LUN. This forces each VM on the LUN to share the same performance characteristics and RAID level with the storage array not changing much in terms of its awareness of housing the VMs.
VVOLs changes this. In a supported VVOL scenario, the storage array is aware it will be storing virtual machine disks (VMDKs). Instead of provisioning a LUN to house the VM, the storage array will provision a VVOL to house the VMDK.
How does that help?
Granularity is the answer here. Looking at the first scenario of having multiple VMs on a LUN, if we were to take a SAN snapshot of that LUN or enable SAN replication on the LUN, we would essentially be snapshotting and replicating all VMs residing on the datastore. And with things like Storage DRS and Storage vMotion we can't necessarily -- without explicit rules -- control which VMs are on that datastore.
With VMware VVOLs, more granular control is possible. If we were to snapshot a VVOL, we are only snapshotting the one VM that belongs to the VVOL; we would only replicate the one VM that resides on that VVOL.
It's all about the policy
This granularity extends further than just array functionality -- it touches on performance as well. Gone are the days of searching a data store that matches a certain RAID level to meet performance standards or SLAs.
Instead, we use a policy-based provisioning technique with vSphere as the intermediary between the vSphere administrator and the storage array. Through the use of vStorage APIs for Storage Awareness (VASA), the storage array will broadcast its capabilities -- replication, compression, RAID levels, SSD and others -- to vSphere. The administrator, when provisioning a VM, will essentially assign a policy to the VM, stating it requires a certain RAID level along with different capabilities, such as replication or deduplication.
We have this functionality with policy-based storage provisioning in vSphere, but VVOLs takes this one step further. Instead of intelligently placing VMs on data stores, VVOLs send the information to the array to create the VVOL for the VM. We provide vSphere with a set of requirements, which then sends those requirements on to the storage array. Then, the array creates the containers for the VMDKs and the VM is placed or created, aligning with the policies and requirements that we've designated.
Will existing storage arrays support VMware VVOLs?
The first challenge that comes to mind is the configuration maximums that align with vSphere. Currently, there is a limit of 256 LUNs per host. This is not an issue when placing many VMDKs on a single data store (LUN) but can quickly become a problem with a one-to-one VMDK-to-VVOL ratio. To avoid this issue, the storage array housing the VVOLs must support a concept dubbed the I/O Demultiplexer.
The I/O Demultiplexer is essentially a device on the storage array that handles the communication between the ESXi hosts and the storage array. By acting as a single channel or connection to the storage array, the I/O Demultiplexer eliminates the issues around configuration maximums.
We have seen many tech previews and press releases from the major storage vendors showing their support for VVOLs, but most of them are only showing the functionality on newer arrays. Will older arrays support VVOLs? One can hope a firmware upgrade will be enough. It remains to be seen if a lot of enterprises will need to upgrade storage arrays to gain VVOL support.
Is IT ready for the change?
Another challenge I can see is more of a business/political/silo issue. While vSphere administrators have long had the power to create VMs, they have always had to go to the storage team to have the data stores provisioned. With VVOLs, storage provisioning is an API call from vSphere, meaning the vSphere admins can deploy the storage as well as the VMs.
This may not be an issue with arrays that are dedicated to vSphere, but if they are shared with other physical applications, bypassing the storage team could be a business challenge for those organizations keeping close ties on storage arrays. To help mediate this problem, VVOLs storage will be presented to vSphere via a storage container or capacity pool. The storage team can control how much and what storage is available to the vSphere administrators.
Are there other possible hurdles?
The last potential issue I can see surrounding VVOLs is in the nature of support. Not support from VMware, but support from the many third-party ecosystem vendors present in our virtualization infrastructure. It's not uncommon to see many applications handling items such as backup, monitoring and automation playing a larger role within environments that depend heavily on hypervisor functions and APIs provided by vSphere. These vendors will also have to adapt to the concept of VVOLs and that may take time and hold back infrastructure changes.
Any new technology comes with difficulties that need to be overcome and VVOLs is no different. That said, the VMDK becoming a first class citizen and a primary object within the storage world will far outweigh any issues or challenges that may arise. As always, people, technology and environments will need to adjust to support it. The policy-based provisioning, coupled with the API automation, will most definitely speed up provisioning, decrease risk within our infrastructure and give us a more granular approach as it pertains to performance and protection within our vSphere environments.