Release Notes

8 Dell Virtual Storage Manager: Installation Considerations and Local Data Protection | 2079-BP-V-VSM
1.1 Introduction to Virtual Volumes
VMware vSphere 6.0 introduces Virtual Volumes (vVols), a significant change in how storage is utilized in a virtualized
environment. Enabled by the second-generation VASA Provider included with Virtual Storage Manager 4.5, this feature
enables storage to be virtual-machine aware, and for virtual machines to be first-class citizens in the storage array.
vVols does not significantly change day-to-day activities for a vSphere administrator; a virtual machine is still a virtual
machine, and the workflows within vCenter do not change. What changes on the storage side is that a virtual machine
consists of a grouping of volumes on the array (explained in section 1.1.2). This change results in storage-centric tasks
being the domain of the array.
1.1.1 Benefits of Virtual Volumes
Cloning a virtual machine, or deploying a virtual machine from a template without vVols, is a large file-copy operation
that is accelerated with the VAAI primitive Full Copy. With vVols, the cloning operation (which is manipulating block
pointers and reserving space) is completed within a matter of seconds.
VMware recommends that when executing virtual machine snapshots, to limit them to 24 or 72 hours and 2-3 delta
files in a chain because performance may be decreased. The workflow remains unchanged, but the old delta file
snapshots become efficient pointer-based snapshots on the array. This results in a rapid creation of snapshots that can
be used for a quick restore and kept for an indefinite period of time.
Note: While the array firmware permits a volume to have 512 snapshots, the current vSphere vVol implementation is
limited to 32 snapshots. Even with this limitation, vSphere administrators are able to complement their current
backup strategy with more frequent and rapidly restorable snapshots.
With vVols, a virtual machine is a group of volumes on the array, this enables the existing Dell SAN Headquarters (SAN
HQ) array performance-monitoring tool to provide a detailed I/O analysis on a per-virtual-machine and per-virtual -disk
level. While similar performance metrics can be seen in vCenter, these are generated from the host side, and cannot
show the same level and detail that can be seen on the array side, such as the impact of I/Os, latency, and block size on
the underlying physical disks. SAN HQ, coupled with the PS Series vCenter Operation Manager™ adapter, makes this
detailed information available within vCenter Operations, and enables both the vSphere administrator and PS Series
array administrator to see the same information from their respective preferred interfaces.
1.1.2 Understanding how Virtual Volumes changes storage
Traditionally, when storage has been deployed to a vSphere environment, a volume is created on the array. This
becomes a datastore within vCenter where virtual machines are placed. With Virtual Volumes, some of this remains the
same; virtual machines are placed within datastores and work flows that depend on this remain unchanged. What has
changed is that the object backing up the datastore is a storage container. While it does contain virtual machines and
backs up a datastore, it should not be thought of as a volume. Rather, think of the storage container as a reservation of
space on the array where virtual machines consume storage. A typical virtual environment design involves using
multiple volumes due to queue depth concerns, SCSI-2 Reservation concerns, and differing data-protection needs. With
vVol storage containers, this changes to potentially having a single storage container for the entire environment, as
Storage Policy Based Management and data-protection policies can be applied at the individual virtual-machine level.