6.0.1

Working with Virtual Volumes 19
The Virtual Volumes functionality changes the storage management paradigm from managing space inside
datastores to managing abstract storage objects handled by storage arrays. With Virtual Volumes, an
individual virtual machine, not the datastore, becomes a unit of storage management, while storage
hardware gains complete control over virtual disk content, layout, and management.
Historically, vSphere storage management used a datastore-centric approach. With this approach, storage
administrators and vSphere administrators discuss in advance the underlying storage requirements for
virtual machines. The storage administrator then sets up LUNs or NFS shares and presents them to ESXi
hosts. The vSphere administrator creates datastores based on LUNs or NFS, and uses these datastores as
virtual machine storage. Typically, the datastore is the lowest granularity level at which data management
occurs from a storage perspective. However, a single datastore contains multiple virtual machines, which
might have dierent requirements. With the traditional approach, dierentiation on a per virtual machine
level is dicult.
The Virtual Volumes functionality helps to improve granularity and allows you to dierentiate virtual
machine services on a per application level by oering a new approach to storage management. Rather than
arranging storage around features of a storage system, Virtual Volumes arranges storage around the needs
of individual virtual machines, making storage virtual-machine centric.
Virtual Volumes maps virtual disks and their derivatives, clones, snapshots, and replicas, directly to objects,
called virtual volumes, on a storage system. This mapping allows vSphere to ooad intensive storage
operations such as snapshot, cloning, and replication to the storage system.
By creating a volume for each virtual disk, you can set policies at the optimum level. You can decide in
advance what the storage requirements of an application are, and communicate these requirements to the
storage system, so that it creates an appropriate virtual disk based on these requirements. For example, if
your virtual machine requires an active-active storage array, you no longer must select a datastore that
supports the active-active model, but instead, you create an individual virtual volume that will be
automatically placed to the active-active array.
This chapter includes the following topics:
n
“Virtual Volumes Concepts,” on page 214
n
“Guidelines when Using Virtual Volumes,” on page 217
n
“Virtual Volumes and Storage Protocols,” on page 218
n
“Virtual Volumes Architecture,” on page 219
n
“Virtual Volumes and VMware Certicate Authority,” on page 220
n
“Before You Enable Virtual Volumes,” on page 221
n
“Congure Virtual Volumes,” on page 221
n
“Provision Virtual Machines on Virtual Datastores,” on page 224
VMware, Inc.
213