NVMe-vVols on the Everpure FlashArray is certified with VMware for vSphere 8.0 U1 and later with Purity//FA 6.6.2 and later.
NVMe-oF vVols Overview
When VMware releases vSphere 8.0 GA they introduced the support for NVMe-oF with vVols for Fibre Channel. In vSphere 8.0 U1 support for NVMe-oF with vVols for TCP was released. Everpure supports both NVMe-oF with TCP and FC for vVols on the FlashArray beginning with Purity//FA 6.6.2.
NVMe-oF Terminology
There are some key terms that should be covered when covering NVMe-oF in general and then with NVMe vVols as well.
Asymmetric Namespace Access (ANA)
Asymmetric Namespace Access (ANA) is an NVMe standard that was implemented as a way for the target (FlashArray) to inform an initiator (ESXi in our case) of the most optimal way to access a given namespace.
Depending on the design of an array, all paths may not be created equal; thus this is a way for the array to inform the initiator of these differences. A common scenario in the storage industry is that each controller "owns" specific resources (such as a namespace) while other controllers do not. While the namespace is still accessible through the secondary controller(s) front-end ports, there may be a performance penalty for doing so, thus accessing the namespace through the owning controller equates to faster service times.
Due to the potential performance penalties the storage array may advertise all of the paths leading to the primary controller as "Optimized" while the paths to the secondary controller(s) as "Non-Optimized". This results in the connected hosts sending I/O to only the "Optimized" as long as they are still available. Should they become unavailable for any reason, only then will the host send I/O to the "Non-Optimized" paths. Obviously, slow I/O is better than no I/O.
A FlashArray utilizing NVMe-oF advertises all paths as "Optimized" to any given host. Due to the design of the FlashArray, there is negligible performance difference between the primary and secondary controllers; thus, "Non-Optimized" paths are not reported.
For the implementation of NVMe vVols, there are two separate controller access expected from storage vendors and will be used by the ESXi NVMe drivers. vVol namespaces are expected to never be advertised by non vVols controllers.
Aysmmetric Namespace Access (ANA) and Asymmetric Logical Unit Access (ALUA) are essentially synonymous with one another. The difference being that the term ALUA is used for SCSI-based storage while the term ANA is used for NVMe-based storage.
Namespace
A volume presented from the FlashArray to the ESXi host is referred to as a namespace. This is the same concept as a Logical Unit (LU) with SCSI-based storage. The concept of NVMe namespaces maps directly to virtual volumes very well and the implementation approach is to map vVols to NVMe namespaces at a one to one basis.
Namespace ID (NSID)
The namespace ID is used as an identifier for a namespace from any given controller. This equates to a Logical Unit Number (LUN) with SCSI-based storage. For NVMe vVols, vSphere expects the array to support a large amount of namespaces, but leaves the management and allocation of NSIDs to the storage provider. vSphere does not store NSIDs nor expect the same NSID to always be used for a given namespace. The VASA specification is designed to not make any assumptions for how arrays allocate NSIDs for the backing vVols or snapshots of vVols.
Virtual Protocol Endpoint
With the SCSI implementation of vVols the use of a Protocol Endpoint was crucial to overcome scaling issues with the number of LUNs being connected to ESXi hosts. With NVMe vVols, while the necessity of Protocol Endpoints as they were used with SCSI was not needed, there was still value in being able to manage multipathing for all vVols on the groups of namespaces that support NVMe vVols, as well as reporting path status.
To achieve this, a "Virtual Protocol Endpoint" is implementing with NVMe vVols. The virtual PE is not representing a specific storage object or "Administrative LUN" as with a SCSI PE, but rather is a host side object that ends up representing all of the NVMe vVols namespace groups as advertised by the storage array. This means that only a single Virtual Protocol Endpoint would show up in the device lists for an ESXi host per storage array. Even if there are multiple NVMe vVols storage containers with multiple PE objects on the array created for them, ESXi will only report a single virtual PE for that storage array.
NVMe Qualified Name (NQN)
The NVMe Qualified Name (NQN) is used to uniquely identify (and authenticate) a target or initiator. Similar to an iSCSI Qualified Name (IQN), there is a single NVMe Qualified Name associated with the FlashArray. The implementation for NVMe vVols has each ESXi host using a unique NQN for vVols and then using a different NQN for standard VMFS or RDM access. ESXi ensures that separate pairs of host NQN and host ID will be used when accessing vVols and non-vVols.