6.0.1

n
A conguration virtual volume, or a home directory, represents a small directory that contains
metadata les for a virtual machine. The les include a .vmx le, descriptor les for virtual disks, log
les, and so forth. The conguration virtual volume is formaed with a le system. When ESXi uses
SCSI protocol to connect to storage, conguration virtual volumes are formaed with VMFS. With NFS
protocol, conguration virtual volumes are presented as an NFS directory.
Additional virtual volumes can be created for other virtual machine components and virtual disk
derivatives, such as clones, snapshots, and replicas. These virtual volumes include a swap virtual volume to
hold virtual machine swap les and a virtual memory volume to hold the contents of virtual machine
memory for a snapshot.
By using dierent virtual volumes for dierent VM components, you can apply and manipulate storage
policies at the nest granularity level. For example, a virtual volume that contains a virtual disk can have a
richer set of data services and performance levels than the virtual volume for the VM boot disk. Similarly, a
snapshot virtual volume can use a dierent storage tier compared to a current virtual volume.
Virtual Volumes and Storage Providers
A Virtual Volumes storage provider, also called a VASA provider, is a software component that acts as a
storage awareness service for vSphere. The provider mediates out-of-band communication between
vCenter Server and ESXi hosts on one side and a storage system on the other.
The storage provider is implemented through VMware APIs for Storage Awareness (VASA) and is used to
manage all aspects of Virtual Volumes storage. The storage provider integrates with the Storage Monitoring
Service (SMS), shipped with vSphere, to communicate with vCenter Server and ESXi hosts.
The storage provider delivers information from the underlying storage, or storage container in the case of
Virtual Volumes, so that storage container capabilities can appear in vCenter Server and the
vSphere Web Client. Then, in turn, the storage provider communicates virtual machine storage
requirements, which you can dene in the form of a storage policy, to the storage layer. This integration
process ensures that a virtual volume created in the storage layer meets the requirements outlined in the
policy.
Typically, vendors are responsible for supplying storage providers that can integrate with vSphere and
provide support to Virtual Volumes. Every storage provider must be certied by VMware and properly
deployed. For information about deploying the Virtual Volumes storage provider, contact your storage
vendor.
After you deploy the storage provider, you must register it in vCenter Server, so that it can communicate
with vSphere through the SMS.
Storage Containers
Unlike traditional LUN and NFS based vSphere storage, the Virtual Volumes functionality does not require
precongured volumes on a storage side. Instead, Virtual Volumes uses a storage container, which is a pool
of raw storage capacity or an aggregation of storage capabilities that a storage system can provide to virtual
volumes.
A storage container is a part of the logical storage fabric and is a logical unit of the underlying hardware.
The storage container logically groups virtual volumes based on management and administrative needs. For
example, the storage container can contain all virtual volumes created for a tenant in a multitenant
deployment, or a department in an enterprise deployment. Each storage container serves as a virtual volume
store and virtual volumes are allocated out of the storage container capacity.
Typically, a storage administrator on the storage side denes storage containers. The number of storage
containers, their capacity and size depend on a vendor-specic implementation, but at least one container
for each storage system is required.
N A single storage container cannot span dierent physical arrays.
Chapter 19 Working with Virtual Volumes
VMware, Inc. 215