The idea of Virtual Volumes has been a long time coming, first having been announced a few years ago at VMworld. After a decade of feeding and caring for VMs, VMware understands it would be helpful if tools and infrastructure also worked at the VM level.
Over the years, vSphere has gotten easier to manage, but there are still a number of challenges. When using NFS storage or legacy LUN, the storage side of things is usually a black hole to admins. The design allows for large groups of VMs to be stored on a chunk of storage; the smallest point of management and reporting in this architecture is a LUN or NFS export.
This legacy architecture has been unable to adapt to the modern data center where flexibility is key. Before tools like vCenter Operations Manager (vCOPs) came along, the management of VM performance was terrible. Admins had the stats from vCenter or ESXTOP, but after that, they were blind. They could ask for performance details for an entire LUN from the storage team, but that might not be a simple request.
For the last several years, another big demand by admins was for the ability to replicate data on a per-VM basis for Site Recovery Manager (SRM). This type of flexibility is essential; many times companies simply give up and replicate entire arrays due to lack of per-VM options.
How VMware VVOLs works
The goal of VMware VVOLs is to get legacy storage and newer block- and file-based storage to offer a form of per-VM management. Rather than creating LUNS and NFS exports that become data stores in vSphere, VVOLs create pools of capacity on storage arrays for different performance characteristics or data services.
The next version of vSphere will use a new intermediate service called the Protocol Endpoint to let ESXi hosts connect to the VVOLs data store. When a VM is provisioned on VVOLs, a small LUN will be created for all the files that make up a VM. When you look in a folder on a data store today for a VM, there are several files that make up the VM. In VVOLs, those files become LUNS.
With VVOLs, administrators will work with VMs instead of the old data store model. You will get the ability over time to set policies and other features on a per-VM basis rather than at the data store level.
How native-VM storage works
For native VM visibility at the storage level, a product will have been built for this purpose from the start. This means the product had to have been developed within the last few years and was designed to see VMs rather than LUNs.
Today, all of the storage vendors that support native-VM visibility are based in NFS. This is likely because it's an easier problem to solve on a file-based solution rather than block-based storage. It could also be that IP storage has really gained a lot of traction in the VMware space, because it can be simple and fast to deploy. With all of these modern offerings, you are able to manage performance, report on capacity, backup and replicate on a per-VM level.
Concerns over VMware VVOLs
It remains to be seen, but it is likely we will have to wait an additional year for the management and DR products to support VVOLs. Vendors will get on board with support for storage systems, but their data services products will take additional time to include this new feature. Certain operations, such as array-based replication, will likely lag behind and since the majority of SRM installs are using array replication, this does very little to help with per-VM DR granularity.
Another concern is that your current storage array may not support VVOLs. As I talk to vendors -- at least in the legacy, three-tier architecture space -- it sounds like a limited amount of current models will support VVOLs. True support will come out with the next generation of the storage systems. This is likely due to a limitation in their current code bases, since VVOLs will cause trouble by adding more LUNS to manage.
Also, I'm not confident that storage vendors will bring a per-VM management experience to the backend storage piece; just because a vendor adds VMware VVOLs and allows vSphere to create VM-based storage on the array, does not mean the array will offer per-VM management and performance reporting. In this new model, each VM can easily be made up of five to 10 LUNs of different sizes. Multiply that by a 1,000 VMs and you've got a serious management nightmare.
Think about trying to correlate a VM to a group of LUNS in the management interface, then try to figure out which is the right one or has performance issues. I've yet to find a storage vendor that wants to show off their backend demo of VVOLs. I am getting the feeling that there will be little change to the management and reporting features of these arrays, and that you will get what you have now, but with significantly more LUNS to look at. This does not excite me.
I think moving towards a per-VM management solution is the right thing. While I'm glad VMware has built this option for vendors, I would rather they find a native way to offer the support and build intelligent features along the way.