Virtual Volumes (VVols) is a new integration and management framework that virtualizes SAN/NAS arrays, enabling a more efficient operational model that is optimized for virtualized environments and centered on the application instead of the infrastructure. Virtual Volumes simplifies operations through policy-driven automation that enables more agile storage consumption for virtual machines and dynamic adjustments in real time, when they are needed. It simplifies the delivery of storage service levels to individual applications by providing finer control of hardware resources and native array-based data services that can be instantiated with virtual machine granularity.
With Virtual Volumes (VVols), VMware offers a new paradigm in which an individual virtual machine and its disks, rather than a LUN, becomes a unit of storage management for a storage system.Virtual volumes encapsulate virtual disks and other virtual machine files, and natively store the files on the storage system.
Virtual Volumes (VVols) are VMDK granular storage entities exported by storage arrays. Virtual volumes are exported to the ESXi host through a small set of protocol end-points (PE). Protocol Endpoints are part of the physical storage fabric, and they establish a data path from virtual machines to their respective virtual volumes on demand. Storage systems enables data services on virtual volumes. The results of these data services are newer virtual volumes. Data services, configuration and management of virtual volume systems is exclusively done out-of-band with respect to the data path. Virtual volumes can be grouped into logicaly and are called storage containers (SC) for management purposes.
Virtual volumes (VVols) and Storage Containers (SC) form the virtual storage fabric. Protocol Endpoints (PE) are part of the physical storage fabric.
By using a special set of APIs called vSphere APIs for Storage Awareness (VASA), the storage system becomes aware of the virtual volumes and their associations with the relevant virtual machines. Through VASA, vSphere and the underlying storage system establishes a two-way out-of-band communication to perform data services and offload certain virtual machine operations to the storage system. For example, operations such as snapshots and clones can be offloaded.
For in-band communication with Virtual Volumes storage systems, vSphere continues to use standard SCSI and NFS protocols. This results in support with Virtual Volumes for any type of storage that includes iSCSI, Fibre Channel, Fibre Channel over Ethernet (FCoE), and NFS.
- Virtual Volumes represent virtual disks of a virtual machine as abstract objects identified by 128-bit GUID, managed entirely by Storage hardware.
- Model changes from managing space inside datastores to managing abstract storage objects handled by storage arrays.
- Storage hardware gains complete control over virtual disk content, layout and management.
Important Things to be noted:
- Storage provider (SP): The storage provider acts as the interface between the hypervisor and the external array. It is implemented out-of-band (it is not data path) and uses the existing VASA (vSphere APIs for Storage Awareness) API protocol. The storage provider also consists of information, such as details on VVOLs and storage containers. VVOLs requires the support of VASA 2.0, released with vSphere 6.
Storage container (SC): This is configured on the external storage appliance. The specific implementation of the storage container will vary between storage Vendors, although most of the vendors allow physical storage to be aggregated into pools from which logical volumes can be created.
- Protocol endpoint (PE): It acts as a middle man between VVOLs and hypervisor and is implemented as a traditional LUN on block-based systems, although it stores no actual data (dummy LUN). The protocol endpoint has also been described as an I/O de-multiplexer, because it is a pass-through mechanism that allows access to VVOLs bound to it. For example the gate keeper LUN in EMC VMAX array.ESXi hosts have no direct access to virtual volumes on the storage side. Instead, ESXi hosts use a logical I/O proxy, called the Protocol Endpoint (PE), to communicate with virtual volumes and virtual disk files that virtual volumes encapsulate.
- VVols Objects:
A virtual datastore represents a storage container in vCenter Server and the vSphere Web Client. Virtual volumes are encapsulations of virtual machine files, virtual disks, and their derivatives.
- Virtual machine objects stored natively on the array storage containers.
- There are five different types of recognized Virtual Volumes:
- Config-VVol – Metadata
- Data-VVol – VMDKs
- Mem-VVol – Snapshots
- Swap-VVol – Swap files
- Other-VVol – Vendor solution specific
Follow these guidelines when using Virtual Volumes:
- Because the Virtual Volumes environment requires the vCenter Server, you cannot use Virtual Volumes with a standalone ESXi host.
- Virtual Volumes does not support Raw Device Mappings (RDMs).
- A Virtual Volumes storage container cannot span across different physical arrays.
- Host profiles that contain virtual datastores are vCenter Server specific. After you extract this type of host profile, you can attach it only to hosts and clusters managed by the same vCenter Server as the reference host.
Key benefits of Virtual Volumes:
- Operational transformation with Virtual Volumes when data services are enabled at the application level
- Improved storage utilization with granular level provisioning
- Common management using Policy Based Management