Unlock Zero RPO with Stretch Clustering over NVMe for VMware

Adoption of NVMe-oF has grown quickly over the past two years. The value that it brings is hard to deny: lower CPU overhead, lower and more consistent latency, significantly more efficient in-band management (no more SCSI rescans). While VMware features like VAAI have been updated to take advantage of this modern framework, there was one critically important use case that was missing: stretched storage, aka vSphere Metro Storage Clustering (vMSC).

With VMware Cloud Foundation (VCF) 9.1, that changes. In the vSphere storage updates for VCF 9.1, Broadcom announced partner-supported NVMe stretch cluster solutions and introduced NVMe dispersed namespaces to enable storage partners to validate and support NVMe-based stretch cluster designs.

What Broadcom announced in VMware Cloud Foundation 9.1

The most important storage item in the VCF 9.1 release notes is short, but significant: VCF 9.1 introduces NVMe dispersed namespaces, and Broadcom explicitly positions them as the enabler for partner-supported NVMe stretched cluster solutions. What does “partner-supported” mean? Essentially, VMware ended their official certification program for stretched storage five years or so ago, leaving it up to partners to test and validate designs. We worked alongside VMware as a design partner to build this feature and validate it.

Use NVMe-oF or traditional storage protocols?

It’s also worth stepping back and looking at why NVMe-oF matters in the first place. Traditional block storage protocols such as iSCSI and Fibre Channel have been the foundation of VMware environments for years, but they were built around the SCSI command set. NVMe over Fabrics extends the NVMe protocol to the storage network, allowing optimized access to storage from the hypervisor.

A simple way to think about the comparison is this:

• iSCSI is familiar and widely deployed, especially in Ethernet-based environments, but it still carries the legacy SCSI model.
• Traditional Fibre Channel is proven and highly reliable, but it also remains tied to SCSI semantics and dedicated FC infrastructure.
• NVMe-oF/TCP brings NVMe over standard Ethernet, which makes it especially attractive for customers who want to modernize without introducing a separate FC fabric.
• NVMe-oF/FC keeps the operational model and hardware infrastructure of Fibre Channel while updating to NVMe as the storage protocol.

For customers already using Everpure™ FlashArray™ with VMware, the appeal of NVMe-oF is not just raw performance. It’s the combination of a protocol designed for flash, better alignment with modern multi-core systems, and a cleaner path forward for next-generation storage architectures. In the context of VCF 9.1, the key takeaway is that stretched storage is no longer limited to older protocol assumptions. Customers can now look at an architecture that combines ActiveCluster™ with NVMe-oF/TCP or NVMe-oF/FC in a VMware-supported model.

What stretched storage over NVMe-oF means

At a high level, stretched NVMe-oF means the same datastore is presented across two sites so hosts on either side can continue to access the same data set. In a FlashArray design, ActiveCluster provides the synchronous replication layer, while NVMe-oF/TCP or NVMe-oF/FC provides the front-end host connectivity from ESXi to the arrays.

The easiest way to think about it is this: ActiveCluster is still doing the storage work, and NVMe-oF changes how that stretched volume is presented to the host. From the ESXi point of view, the goal is for the stretched volume to look like one shared device with multiple paths rather than two separate devices.

That distinction matters on the write path. In normal steady-state operation, a write is not acknowledged back to the host until it’s protected in NVRAM on both arrays, which is what gives ActiveCluster its zero-RPO behavior at the storage layer. Reads are different: They usually follow the normal local read path and do not need that replication round trip unless connectivity or failover conditions force access to the remote side.

What’s a dispersed namespace?

Let’s explain what a namespace is first. An NVMe namespace is the logical block device presented to the host over NVMe. If you’re used to SCSI terminology, the easiest comparison is a LUN—it’s the storage object the host discovers, identifies, and ultimately formats with a filesystem such as VMFS. The difference is that NVMe uses NVMe-native constructs such as namespaces, controllers, NSIDs, and EUI/NGUID identifiers rather than SCSI LUN semantics. That distinction becomes important in a stretched design because once you understand that a namespace is the host-visible NVMe device, a dispersed namespace is simply the next step. The same namespace identity is presented across more than one NVMe subsystem so the host can treat both sides of the stretch as paths to the same logical device rather than two separate devices.

A dispersed namespace is the NVMe mechanism that allows the same namespace identity to be presented to a host from two or more NVMe subsystems at the same time. In the context of stretched storage, that means the host can understand that the namespace it sees from Site A and the namespace it sees from Site B are two paths to the same logical device, not two unrelated namespaces. That’s the key host-side enabler for stretched NVMe. 

For a long time, the missing piece was not synchronous replication itself. ActiveCluster already provided the storage-side replication, consistency, and failover behavior. The gap was on the host side: Traditional stretched storage workflows were built around SCSI-era assumptions, while NVMe needed a way for the host and multipathing stack to correctly understand a stretched namespace across sites.

That’s why dispersed namespaces matter. They provide the host-side model that lets stretched NVMe behave like stretched storage instead of just looking like two independent NVMe presentations. Broadcom added that support in ESXi 9.1+, and Everpure built the corresponding implementation so FlashArray ActiveCluster could present stretched NVMe volumes in a way that preserves consistent device identity, host multipathing behavior, and failover safety.

Figure 1: High-level architecture of ActiveCluster over NVMe-oF with VMware Cloud Foundation 9.1 across two sites.

What’s needed for FlashArray ActiveCluster with NVMe-oF, and how do you configure it?

The baseline requirements are straightforward:

• Purity//FA version 6.10.5 or higher
• VMware Cloud Foundation 9.1 with ESXi 9.1 hosts
• NVMe-oF/TCP or NVMe-oF/FC as the host transport
• A stretched VMFS datastore backed by ActiveCluster
• In VCF, the datastore is used as external or supplemental storage for workload domains
• Both uniform and non-uniform ActiveCluster configurations are supported

From there, the implementation comes down to a few key configuration steps:

1. Collect and register each ESXi host NQN.

Get the ESXi NQN, the identifier you register on both FlashArray systems for the host object.

esxcli nvme info get

2. Create NVMe-oF host objects on both arrays.
3. Set the host personality and enable nvme-stretch.

For each host that will participate in NVMe-oF ActiveCluster, set personality to ESXi9.1 using the following command:

purehost setattr --personality esxi9.1 <HOST_NAME>

For each host that will participate in NVMe-oF ActiveCluster, configure nvme-stretched mode using the following command:

purehost setattr --nvme-stretch allow <HOST_NAME>

4. Create the volume in the stretched pod and connect it on both arrays.

Once the host is registered and the stretched volume is connected on both arrays, the next VMware-side confirmation is under the NVMe adapter’s Devices tab, where the namespace-backed device should appear as storage visible to the host.

To inspect the NVMe controllers and namespaces from the ESXi side, the useful ESXi CLI commands are:

esxcli nvme controller list
esxcli nvme namespace list
esxcli nvme namespace list --controller-number <id>

What are you looking for in the output? In a dispersed namespace design, you want to see the namespace discovered through the NVMe controllers that represent connectivity to the stretched configuration. The expected result is that controllers from both arrays are visible with one logical namespace identity for the stretched volume.

5. Create the VMFS datastore in vSphere Client.

From there, datastore creation looks familiar. You create a VMFS datastore manually in vSphere Client, select the NVMe-backed device, and once the datastore is created, it should mount across the ESXi cluster.

For detailed implementation and configuration details, please refer to this knowledge base article on the Everpure Support site or follow instructions in this how-to video.

FlashArray ActiveCluster datastores over NVMe-oF/TCP or NVMe-oF/FC are also supported with clustered VMDKs, which is relevant for Windows Server Failover Clustering use cases that need shared VMDKs on VMFS.

How do you map the VMware device back to the FlashArray volume?

ActiveCluster stretched volume keeps the same volume serial number on both arrays, which is why the host can recognize paths from both arrays as paths to the same volume rather than two separate devices.

The NVMe-specific view is even more useful. On ESXi, the namespace identifier shows up as an eui.* device rather than a SCSI naa.* device. The Everpure namespace NVMe NGUID/EUI can be decoded into three parts: The first part reflects the FlashArray ID, the middle bytes include Everpure company identifier 24a937, and the final bytes identify the individual volume. If you grep those final bytes in purevol list, you can map the ESXi namespace back to the exact FlashArray volume.

A compact example looks like this:

# On ESXi
esxcli nvme namespace list

# Example device
# eui.003b7b308d98f94224a9375e00018816

# On FlashArray
purevol list | grep -i 5e00018816

VMware shows the namespace as an eui identifier, and the tail of that identifier can be matched directly back to the Everpure volume. That’s the NVMe equivalent of what VMware admins are used to doing with naa identifiers on SCSI devices.

One subtle but useful detail to call out is that VMware’s displayed LUN value does not map one-to-one with the FlashArray GUI LUN concept for NVMe. VMware shows the namespace ID minus one, so you should not expect the VMware LUN field to be the authoritative mapping key. The eui identifier is the better correlation point here.

How do you migrate from legacy SCSI devices to NVMe-oF?

For VMware, the migration from SCSI to NVMe-oF is best treated as a datastore migration, not a protocol conversion in place. Because SCSI and NVMe differ in reservation handling and device identity, the operationally clean path is to deploy new NVMe-oF datastores and use Storage vMotion to move workloads from the legacy FC or iSCSI datastores.

Practical migration path:

1. Stand up new NVMe-oF connectivity on the ESXi cluster using NVMe-oF/TCP or NVMe-oF/FC.
2. Present new NVMe-oF VMFS datastores to the hosts. For VMware NVMe-oF, VMFS is supported; RDM is not.
3. Run Storage vMotion for the VMs from the legacy SCSI datastore to the new NVMe-oF datastore, ideally in controlled batches.
4. Validate performance and application behavior after each batch, then repeat until the source datastore is empty.
5. Unmount and detach the old SCSI datastore once rollback is no longer needed.

What’s coming next?

ActiveCluster with NVMe-oF is fully supported today. What’s coming next with ActiveCluster? Today, FlashArray File Services do not support ActiveCluster; file replication on FlashArray currently relies on ActiveDR™ rather than synchronous ActiveCluster-style stretching. But that’s changing. ActiveCluster for file represents a major next step in extending the FlashArray resilience story beyond block workloads.