Introduction to Virtual Volumes

Traditional storage provisioning of VMware-based virtual machines was done via a datastore mechanism.

1. VMware administrator requests storage
2. Storage administrator creates a “LUN” and provisions it to the ESXi environment via SAN protocol, such as iSCSI or Fibre Channel.
3. VMware administrator rescans the SCSI bus of the ESXi host(s), identifies the device, and then formats it with the Virtual Machine File System (VMFS).
4. A virtual machine is then created with various virtual disks. Each virtual disk was a file on that datastore. These virtual disks were then presented as block devices back up the virtual machine.

   While this process could be automated via plugins and the like, it still presented a variety of problems. First off, every time additional capacity was needed, this process was required to be followed. Also, if a virtual machine needed a certain array feature (replication for instance), how was that achieved? Array based replication was at the datastore level, so enabling a feature on that datastore affected all of the other virtual machines on that datastore (for better or for worse). Furthermore, how could the VMware administrator be sure that feature was, at any point in the future, still configured properly or even enabled?

   There were not a lot of great answers to these questions.

   Enter VMware vSphere Virtual Volumes (henceforth referred to as vVols).

   vVols solve these problems. At a high level, vVols offer the following benefits:

5. Virtual Disk granularity on the array: Each virtual disk is a physical volume on the array.
6. Automatic Provisioning: When a new virtual disk is requested for a VM, VMware automatically has the array create a corresponding volume and present it to that VM. A 100 GB virtual disk means a 100 GB volume on the array. When that virtual disk is resized, so is the array volume. When the virtual disk is deleted, so is the array volume.
7. VM-insights on the array: Since the array now sees each virtual disk, it can report on that granularity. The array also understands the virtual machine object, so an array can now manage and report on a VM itself or its individual virtual disks.
8. Storage Policy Based Management: Since the array now has virtual disk granularity, features like array snapshots or array-based replication can be provided at the exact granularity needed. With vVols, VMware can communicate to the array to find out what features it supports and allow the VMware administrator to assign, change, or remove functionality on a vVol on demand and via policies. If a storage administrator overrides a configured feature on a vVol, the VMware administrator is alerted because the VM is marked as non-compliant with its assigned policy.