6.0.1

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 dierent 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.
Virtual Volumes Part 2: Architecture
(hp://link.brightcove.com/services/player/bcpid2296383276001?
bctid=ref:video_vvols_part2_architecture)
Virtual Volumes and VMware Certificate Authority
vSphere 6.0.x includes the VMware Certicate Authority (VMCA). By default, VMCA generates all internal
certicates used in vSphere environment, including certicates for newly added ESXi hosts and storage
VASA providers that manage or represent Virtual Volumes storage systems.
Communication with the VASA provider is protected by SSL certicates. These certicates can come from
the VASA provider or from VMCA.
n
Certicates can be directly provided by the VASA provider for long-term use, and can be either self-
generated and self-signed, or derived from an external Certicate Authority.
n
Certicates can be generated by VMCA for use by the VASA provider.
When a host or VASA provider is registered, VMCA follows these steps automatically, without involvement
from the vSphere administrator.
1 When a VASA provider is rst added to vCenter Server storage management service (SMS), it produces
a self-signed certicate.
2 After verifying the certicate, SMS requests a Certicate Signing Request (CSR) from the VASA
provider.
3 After receiving and validating the CSR, SMS presents it to VMCA on behalf of the VASA provider,
requesting a CA signed certicate.
VMCA can be congured to function as a standalone CA, or as a subordinate to an enterprise CA. If
you set up VMCA as a subordinate CA, VMCA signs the CSR with the full chain.
4 The signed certicate along with the root certicate is passed to the VASA provider, so it can
authenticate all future secure connections originating from SMS on vCenter Server and on ESXi hosts.
vSphere Storage
220 VMware, Inc.