Virtual Volumes is the flagship feature of vSphere 6.0 as they enable VM granular storage management and NetApp FAS running Clustered Data ONTAP 8.3 is one of the first platforms to support the technology.
Today storage administrators have to explain to the VM administrators how to identify which datastores to use for each class of VM, which is typically achieved using a combination of documentation and datastore naming conventions – however, consistency and compliance are difficult to achieve.
Virtual Volumes changes this by enabling the storage administrator to provide vCenter with detailed information on the capabilities of each datastore. VM Storage Policies, whilst they existed in previous versions of vSphere were not sophisticated enough to query the actual storage for its capabilities, the VMware APIs for Storage Awareness (VASA) Provider 2.0 resolves this problem. Now the VM administrator can create VMs using Virtual Volumes and use the VM Storage Policy wizard to easily determine which datastores are compatible with its needs.
What components are required for Virtual Volumes?
VASA Provider (VP)The NetApp VP is deployed as an OVA virtual appliance and is managed by the Virtual Storage Console plugged in to the vSphere Web Client. VMs running on Virtual Volumes require that the VP is running in order to create the swap Virtual Volume at power on – the VP should not be running on Virtual Volumes since it would be dependent on itself.
Storage Container (SC)A SC is a set of FlexVol volumes used for Virtual Volume datastores. All the FlexVols within a SC must be accessed using the same protocol (NFS, iSCSI, or FC) and be owned by the same Storage Virtual Machine (SVM), but they can be hosted on different aggregates and nodes of the NetApp cluster.
Protocol Endpoint (PE)The IO path to a Virtual Volume is through a PE with the Virtual Volume bound to the PE through a binding call managed by the VP. The VP determines which PE is on the same node as the FlexVol containing the Virtual Volume and binds the Virtual Volume to that PE.
For block protocols, a PE is a small (4MB) LUN, and the VP creates one PE in each FlexVol that is part of a Virtual Volume datastore. The PE is automatically mapped to initiator groups created and managed by the VP.
For NFS, a PE is a mount point to the root of the SVM and is created by the VP for each data LIF of the SVM using the LIF’s IP address. The PE is automatically created when the first Virtual Volume datastore is created on the SVM along with the appropriate export policy rules.
Storage Capability Profile (SCP)A SCP is a set of capabilities for a volume or set of volumes and may include features such as availability, performance, capacity, space efficiency, replication or protocol.
How could things be improved in the future?
Today De-duplication, Compression, SnapMirror and SnapVault policies are applied to FlexVols – it would be useful if they could also be specified for an individual Virtual Volume, which in turn would enable MetroCluster to non-disruptively “move” an active Virtual Volume from one site to another.
It is great to see that NetApp is ahead of the game with regard to support for Virtual Volumes – it is also nice to see that the 8.3 release can be installed on older versions of hardware allowing FAS customers, who purchased their systems a number of years ago, to take advantage of Virtual Volumes.