What is Virtual Volumes (VVOLS)?

Virtual Volumes (VVOLS)

Until recently, storage administrators have been somewhat limited in the flexibility given to them by their datastores. All the virtual machines linked to a particular LUN would have to be treated in the same way – they would all have to be backed up at the same time, for example, or all archived in the same way, even when they served very different purposes. Storage management was ‘LUN-centric’. “Virtual Volumes” (or VVOLs) makes it ‘VM-centric’ for the first time, by enabling administrators to treat each VM individually. With data services, stats, and reporting now available for each VM, management, and troubleshooting is faster and more detailed than ever before.

VVOLs encapsulate (i.e., contain within themselves) virtual disks and other virtual machine files. They are located directly (“natively”) on a physical storage array without using a file system.

VVOLs can broadly be classified into five types:

1. Config-VVOLs contain VMX (the primary configuration file), NVRAM (the file that stores the state of the virtual machine’s BIOS; the BIOS controls the booting process), and log files
2. Data-VVOLs contain data related to VMDKs (virtual disk drives which store the contents of the virtual machine’s storage device) and delta files (a snapshot file – snapshots being copies of VMDKs taken at a specific point in time)
3. Mem-VVOLs contain data related to memory snapshots (which are more detailed snapshots)
4. Swap-VVOLs contain information about swap (memory) files
5. Other-VVOLs are a generic type of VVOL containing files relating to particular vSphere features.

When a virtual machine is created or cloned, or a snapshot is taken of one, a VVOL is automatically created. Every VM will have a config-VVOL. When a VM is powered-on, a swap-VVOL will be created. (It will be deleted when the machine is powered off, and the array will reallocate the space.) As you add virtual disks, each one will have a data-VVOL. Additional VVOLs can be created for other virtual machine components and for items derived from virtual disks, such as clones, snapshots, and replicas.

ESXi hypervisors (which create and run the virtual machines) do not have direct access to virtual volumes. They use “protocol endpoints” to communicate with VVOLs and the virtual disk files that they encapsulate. Each virtual volume is bound to a specific protocol endpoint, but each protocol endpoint can connect to hundreds or thousands of virtual volumes.

For management purposes, VVOLS are grouped into “storage containers”, which are pools of raw storage capacity provided by the storage arrays to the VVOLs. Storage administrators set VVOLs up and can control their size and number. The ability to adjust the size of VVOLs is another example of the flexibility they bring, as LUNs have a fixed size. At least one storage container per array is required, and its size will depend on the physical storage capacity of the array. A single container can be simultaneously accessed through multiple protocol endpoints. Multiple containers can be created depending, again, on the storage array capacity. Containers can’t, however, go across multiple storage arrays. Each storage container serves as a virtual volume store, and virtual volumes are allocated out of the storage container capacity.

Storage containers are not visible to a vSphere administrator. In the vSphere Client they are represented by familiar datastores:

Although they might appear as two different entities, in reality, a virtual datastore is nothing but a storage container in disguise. (However, vSphere needs to preserve the concept of a data store for virtual volumes because several vSphere features use datastores as the main unit of storage.) A vSphere administrator will use the datastore wizard to link (or “map”) storage containers to virtual datastores. The virtual datastore that they create will correspond directly to a specific storage container and will represent that container in vCenter Server and the vSphere Client. From the perspective of the vSphere administrator, the virtual datastore is similar to any other datastore and is used to hold virtual machine files.

VVOLs use “storage providers” (also known as “VASA providers”) to manage all aspects of their storage. A storage provider delivers information from the underlying storage container. The storage container capabilities appear in vCenter Server and the vSphere Client. Then, in turn, the storage provider communicates virtual machine storage requirements. VASA (which stands for “vStorage APIs for Storage Awareness”) is a set of application program interfaces (APIs) that enables vSphere vCenter to recognize the capabilities of storage arrays. (We’ll be looking at APIs in section 5.4.)

The virtual volume is an industry-wide initiative supported by all the major storage vendors.