An architectural diagram provides an overview of how all components of the Virtual Volumes functionality interact with each other.
Virtual volumes are objects exported by a compliant storage system and typically correspond one‐to‐one with a virtual machine disk and other VM-related files. A virtual volume is created and manipulated out‐of‐band, not in the data path, by a VASA provider.
A VASA provider, or a storage provider, is developed through vSphere APIs for Storage Awareness. The storage provider enables communication between the vSphere stack — ESXi hosts, vCenter server, and the vSphere Web Client — on one side, and the storage system on the other. The VASA provider runs on the storage side and integrates with vSphere Storage Monitoring Service (SMS) to manage all aspects of Virtual Volumes storage. The VASA provider maps virtual disk objects and their derivatives, such as clones, snapshots, and replicas, directly to virtual volumes on the storage system.
ESXi hosts have no direct access to the virtual volumes storage. Instead, the hosts access virtual volumes through an intermediate point in the data path, called the protocol endpoint. Protocol endpoints establish a data path on demand from virtual machines to their respective virtual volumes and serve as a gateway for direct in-band I/O between ESXi hosts and the storage system. ESXi can use Fibre Channel, FCoE, iSCSI, and NFS protocols for in-band communication.
Virtual volumes reside inside storage containers that logically represent a pool of physical disks on the storage system. In the vSphere stack, storage containers are presented as virtual datastores. A single storage container can export multiple storage capability sets. As a result, when you create a virtual machine on the virtual datastore, you can use different storage policies to place virtual volumes inside the same storage container in such a way that diverse storage needs of a virtual machine are met.
Watch the video for information about Virtual Volumes architecture.