If you have never worked in a large environment, then you will likely have never run into virtualization limitations with regard to storage: 256 LUNs per ESXi host—which, consequently means, per cluster—with a limit of 1024 paths to those LUNs, and other limitations, then perhaps you might not see a need. But imagine you had a 64-host cluster, which is now possible, but you are limited to 256 LUNs—that's an average of 4 LUNs per server. Ouch. Yes, those LUNs can be huge, but then you run into other problems!
In addition to that, for a long time we in the storage industry have practiced workload segregation—different IO profiles have different workload characteristics. An Exchange database has different storage characteristics and thus requires a different storage profile than a file server. That's not changing. In fact, it is somewhat getting worse: workloads are becoming even more unpredictable and changing rapidly.
VAAI | VMware APIs for Array Integration. Also called hardware or storage array offload, VAAI is a collection of APIs that, in simple terms, relieve ESXi of some storage overhead by offloading the work to arrays identified as capable of performing it.
The APIs define a set of “storage primitives” that enable the ESXi host to offload certain storage operations to the array, which reduces resource overhead on the ESXi hosts and can significantly improve performance for storage-intensive operations such as storage cloning, zeroing, and so on. The goal of VAAI is to help storage vendors provide hardware assistance to speed up VMware I/O operations that are more efficiently accomplished in the storage hardware. — VMware TR 10337
VASA | VMware APIs for Storage Awareness. VASA is a complement to VAAI. While an array may advertise directly to the ESXi host kernel its fundamental storage characteristics (i.e., is it an SSD, does it have VAAI capabilities, and so forth), VASA provides enable full integration into the storage environment, allowing for the correlation of LUN and ESXi events, for example, monitoring and reports of usage, trending, and troubleshooting analysis. Most importantly for VVols, VASA providers enable policy-based management within ESXi by integrating into vCenter and communicating with the backend array. (click for larger image)
Storage Container. VVols live in storage containers. Storage containers may be contain a single VVol, or thousands of them. Instead of creating multiple LUNs or mounts to present to ESXi, the storage admin will create only the amount of storage containers as is needed for 1) space and 2) storage characteristics. Each container itself has a set of capabilities, and those capabilities are logically presented to ESXi for correlation of a storage profile and compliant placement and monitoring of a VVol.
Storage Profile. A storage profile is a group of storage policies that work together to define a VVol's characteristics and allowable features. Should it be deduplicated? How much bandwidth can it consume? What kind of other features should it have? Should it be replicated to the Disaster Recovery site?
So, I don't have to worry about workload segregation, necessarily. I might still want this, but the idea of making sure my application gets a guaranteed number of IOPs or maintains a <10ms latency is very appealing. While VVols is complicated, in the end what is does is simplify management by enable per-vDisk (which is a single VVol) granular-level control that was never before possible unless you wanted to create a dedicated LUN or mount for a single VMDK—and that's a LOT of administrative overhead.
I can imagine that every storage admin reading this right now is thinking, "Whoa—VM admins are going to be provisioning and defining their own storage characteristics? That's dangerous." And it could be. What if a junior admin decided he wanted to create a new VM and gave it guaranteed bandwidth of 1000MBs, thinking it was 1000Mbps? Yeah.
Well, there is a mitigation process for that. When a storage admin creates a Storage Container, he or she will define the storage capabilities, which in turn are presented to the ESXi host. The storage admin can maintain the control of these policies. Duncan Epping says it this way:
Profiles are a set of QoS parameters (performance and data services) which apply to a VM Volume, or even a Capacity Pool. The storage administrator can create these profiles and assign these to the Capacity Pools which will allow the tenant of this pool to assign these policies to his VM Volumes.