6.5.1

Table Of Contents
Protocol endpoints are managed per array. ESXi and vCenter Server assume that all protocol endpoints
reported for an array are associated with all containers on that array. For example, if an array has two
containers and three protocol endpoints, ESXi assumes that virtual volumes on both containers can be
bound to all three protocol points.
Binding and Unbinding Virtual Volumes to Protocol Endpoints
At the time of creation, a virtual volume is a passive entity and is not immediately ready for I/O. To access
the virtual volume, ESXi or vCenter Server send a bind request.
The storage system replies with a protocol endpoint ID that becomes an access point to the virtual
volume. The protocol endpoint accepts all I/O requests to the virtual volume. This binding exists until
ESXi sends an unbind request for the virtual volume.
For later bind requests on the same virtual volume, the storage system can return different protocol
endpoint IDs.
When receiving concurrent bind requests to a virtual volume from multiple ESXi hosts, the storage system
can return the same or different endpoint bindings to each requesting ESXi host. In other words, the
storage system can bind different concurrent hosts to the same virtual volume through different endpoints.
The unbind operation removes the I/O access point for the virtual volume. The storage system might
unbind the virtual volume from its protocol endpoint immediately, or after a delay, or take some other
action. A bound virtual volume cannot be deleted until it is unbound.
Virtual Volumes Datastores
A Virtual Volumes (VVol) datastore represents a storage container in vCenter Server and the
vSphere Web Client.
After vCenter Server discovers storage containers exported by storage systems, you must mount them as
Virtual Volumes datastores. The Virtual Volumes datastores are not formatted in a traditional way like, for
example, VMFS datastores. You must still create them because all vSphere functionalities, including FT,
HA, DRS, and so on, require the datastore construct to function properly.
You use the datastore creation wizard in the vSphere Web Client to map a storage container to a Virtual
Volumes datastore. The Virtual Volumes datastore that you create corresponds directly to the specific
storage container. The datastore represents the container in vCenter Server and the vSphere Web Client.
From a vSphere administrator prospective, the Virtual Volumes datastore is similar to any other datastore
and is used to hold virtual machines. Like other datastores, the Virtual Volumes datastore can be browsed
and lists virtual volumes by virtual machine name. Like traditional datastores, the Virtual Volumes
datastore supports unmounting and mounting. However, such operations as upgrade and resize are not
applicable to the Virtual Volumes datastore. The Virtual Volumes datastore capacity is configurable by the
storage administrator outside of vSphere.
vSphere Storage
VMware, Inc. 271