One problem with server virtualization is that it evolved much faster than physical hardware. Although today's server hardware is virtualization-aware, the same can't be said for infrastructure components, such as networking and storage hardware. This means many organizations have virtual machines (VMs) running on storage hardware that was not specifically designed for handling virtualized workloads.
VM-aware storage is one solution to this issue. The term VM-aware storage refers to storage that was specifically designed for use in virtualized environments. In theory, VM-aware storage should do a better job of handling multiple I/O-intensive workloads that are competing for IOPS than generic storage.
In a way, the VMware Virtual Volumes (VVOLs) feature introduced in vSphere 6 can be thought of as a tool to make an organization's storage VM-aware. VVOLs change the way storage is managed. Instead of working with individual LUNs and volumes, storage administrators can define storage containers and assign policies that outline their functionality. For example, a storage admin might define policies that allow cloning, snapshots and so on.
Once a storage admin defines containers and policies, the virtualization admin matches an appropriate policy to any new VMs that are created. VVOLs then work to map the VM to storage that can deliver the capabilities associated with the chosen policy.
However, an organization can only use VVOLs if they are running vSphere 6 and if their storage vendor supports the use of VVOLs. This means a storage vendor has to make a conscious choice to implement the necessary VMware APIs.
That means VVOLs don't do anything to eliminate the need for VM-aware storage. If anything, VVOLs could be thought of as a mechanism for leveraging VM-aware storage.
Pin down the value of VM-aware storage
The pros and cons of hypervisor-aware storage
Do we need VM-aware storage for virtual workloads?