Release Notes

6 VMware vSphere Virtual Volumes on Dell PS Series | 2028-N-WP-V
2 Virtual Volumes or Virtual Machine File System
Virtual Machine File System (VMFS) and SAN volumes have been doing a satisfactory job for over a decade; why the
need for change? Rather than accepting the satisfactory job that VMFS has been doing, we need to consider the
limitation that VMFS has placed on the virtual environment, and the work-around or best practices that have come into
play to smooth over these limitations.
2.1 VMFS limitations
• Cumbersome management of virtual machine to volume relationship
Queue depth, SCSI-2 conflicts, capacity, data-protection needs, and other variables all play a role in deciding
which traditional datastore contains a virtual machine. However, obtaining this information is time consuming
and complex. In an attempt to respond to an issue before a significant problem arises, rules of thumb are
invoked and metrics are observed. Virtual Volumes move away from VMFS, enabling per-virtual-machine data
protection, and leveraging singular large storage containers and always thin virtual disks to simplify virtual
machine placement.
• No insight to a virtual machines true space and performance consumption
The performance and consumption statistics that the vSphere administrator and storage administrator see are
different. While the vSphere administrator can see individual Virtual Machine Disk (VMDK) I/O metrics, the
storage administrator can only see the I/O metrics for the entire volume where that VMDK resides (which will
include the metrics of several other VMDKs). This difference in information can result in delayed diagnosing
and resolution of a performance issue. With Virtual Volumes, both administrators have visibility to the same
level and detail of I/O metrics in their preferred tool.
• All data services at a volume level
SAN storage array provides a number of data protection capabilities, such as snapshots. However, a SAN only
performs these on a per-volume basis. With traditional datastores, the vSphere administrator has to choose
between short-lived but per-virtual-machine, VMware-based snapshots, or long life SAN-based snapshots that
included all virtual machines on the volume. With Virtual Volumes, vSphere administrators gain the granularity
of per-virtual-machine SAN-based snapshots.
• Need for over provisioning
When sizing datastores for capacity, space must be set aside to accommodate growth of thin provisioned
VMDKs, vswap files, and VMware snapshot delta files. Even though this space may infrequently or never used,
it must be set aside on each datastore. With the shift to Virtual Volumes, multiple traditional VMFS datastores
are replaced with one large storage-container-backed datastore, resulting in this slack space being sharable
across more virtual machines and less slack space needing to be maintained.
• Frequent data migrations