Offset VMware Licensing Costs by Turning Stranded NFS Space into Usable Capacity

For years, VMware customers have enjoyed efficient space reclamation on VMFS and vVol datastores: When a guest OS issues a UNMAP/trim, ESXi can pass that intent down to the storage array and reclaim dead space on thin‑provisioned volumes. On NFS datastores, that story has been very different.

Guest operating systems running on NFS datastores could delete data and issue UNMAP, but the ESXi NFS client had no way to communicate that intent over the NFS protocol. The result is stranded capacity and a noticeable feature gap between file and block for Tier‑1 VMware workloads.

With UNMAP for VMware NFS datastores on Everpure™ FlashArray™, we’re closing that gap in a first‑of‑its‑kind way—co‑designed with VMware, implemented through the VAAI-NAS plugin, and built to behave as naturally as UNMAP on VMFS or vVols. 

The problem: Stranded space on NFS datastores

Guest OSes running on devices backed by NFS datastores have historically been unable to reclaim previously allocated space when those blocks become free again.

On VMFS and vVols, the guest issues UNMAP/trim on a virtual disk, ESXi translates that into a protocol‑level UNMAP or equivalent command, and the storage array deallocates the corresponding ranges on the volume. On NFS datastores, the virtual disk is instead a file on an NFS share. NFSv3 and NFSv4.1 do not define a native UNMAP/TRIM primitive, so ESXi’s NFS layer simply returns EOPNOTSUPP to the guest when it attempts UNMAP. From the array’s point of view, the backing file only ever grows; it does not “know” which ranges inside that file are now logically free.

To work around this, many administrators resorted to tools like SDelete, fstrim, or PowerShell scripts that re‑allocate blocks in the guest, overwrite them with zeros, and hope the storage array detects long runs of zeros and converts them back to free space. It works, but it’s inefficient in every layer: extra CPU and I/O in the guest, extra traffic over the network, and extra protocol processing and data reduction work on the array.

Why VAAI-NAS is the right foundation

VMware already had a clean solution to out‑of‑band communication with storage arrays for NFS using VAAI‑NAS. For NFS datastores, VAAI-NAS introduces an ESXi host plugin (a VIB) that implements NAS‑specific VAAI primitives as an out‑of‑band control channel, offloading operations such as full file clone, fast file clone, and space reservation to the array. ESXi continues to use NFSv3/NFSv4.1 for data I/O, while sending higher‑level storage operations through the plugin.

Everpure already uses this mechanism to offload Storage vMotion and clone operations via full file clone, to offload snapshot and linked‑clone style workflows via fast file clone, and to enable thick VMDKs on NFS via reserve space. The logical next step was to extend this ecosystem with a new UNMAP primitive for NFS datastores.

To make that concrete, it helps to compare what happens without and with VAAI‑NAS UNMAP.

Figure 1: Side‑by‑side comparison. Left: Without VAAI‑NAS UNMAP, the ESXi NFS client has no way to pass UNMAP to the array, so free space remains stranded inside individual VMDKs on the FlashArray. Right: With VAAI‑NAS UNMAP, guest UNMAP flows through ESXi and the VAAI-NAS plugin to FlashArray, which deallocates freed regions and returns them to a common free space pool instead of trapping them inside per‑VM allocations.

What’s new: UNMAP as a VAAI-NAS primitive

Together with VMware, we’ve added UNMAP support to the VAAI-NAS path for NFS datastores backed by FlashArray.

The lifecycle begins in the guest VM. When a guest OS deletes data or runs UNMAP/trim—for example, a Windows guest running SDelete in trim mode or a Linux guest with discard enabled or fstrim scheduled on the filesystem—the guest sends a standard UNMAP request against the virtual disk. On NFS datastores, instead of failing with EOPNOTSUPP, the ESXi NFS storage stack now translates the guest’s UNMAP into a VAAI‑NAS UNMAP request and calls into the VAAI-NAS plugin.

The VAAI-NAS plugin then sends a batched UNMAP request to FlashArray. It identifies the backing VMDK file on the NFS export and a set of file ranges (offset/length pairs) that are now logically free and issues them as a batched UNMAP operation to the array, out‑of‑band from the data path. FlashArray uses its native file architecture to deallocate those byte ranges so that capacity previously tied up in those regions becomes reusable for new allocations in the array. From there, ESXi and the guest simply see reclaimed space: The guest’s UNMAP operation succeeds, ESXi’s view of thin‑provisioned consumption drops as FlashArray frees space, and administrators see more accurate and responsive space utilization on NFS datastores.

Under the covers, VMware also defined a companion primitive, GET_UNMAP_GRANULARITY, which the VAAI-NAS plugin uses to fetch the array’s preferred UNMAP characteristics—alignment, minimum granularity, and so on—so that UNMAP operations are efficient and well‑aligned to the FlashArray system’s internals. The net effect is that NFS datastores now behave like VMFS/vVols from a space reclamation perspective, without requiring any special behavior from the guest beyond standard UNMAP support.

Why this is an industry first

UNMAP on NFS datastores is not “just another knob.” The NFS protocols themselves have no concept of UNMAP, so supporting real, efficient reclamation requires a new control plane between ESXi and the array. VAAI‑NAS UNMAP is that control plane, and it is a new primitive that Everpure co‑designed with VMware.

We worked directly with the VMware engineering team to define how UNMAP calls should be expressed in the VAAI-NAS API, to agree on how to identify VMDK files and their relevant regions, and to handle batching, error propagation, and corner cases in a way that fits naturally into the ESXi storage stack. FlashArray is the first array to implement this end‑to‑end for VMware NFS datastores. This is the first generally available implementation that offloads UNMAP for VMware NFS datastores using VAAI-NAS.

Put simply, NFS datastores on FlashArray are the first in the industry to offer native, protocol‑independent UNMAP for VMware via VAAI‑NAS.

How Everpure innovated under the hood

Several aspects of the implementation lean heavily on the FlashArray unified block and file architecture and the Everpure VMware integration stack.

Fundamentally, FlashArray is designed not to lock capacity into rigid, siloed containers. Many legacy architectures carve a system into fixed allocation groups or pools, and once space is consumed inside one of those silos, it can be difficult to return it to a truly shared pool without disruptive reshaping or migration. FlashArray instead exposes a single, global pool of capacity with always‑on data reduction. Allocations can move and be reclaimed transparently inside that pool, which is why features such as thin provisioning, snapshots, and replication do not force you into complex capacity engineering per “container.”

On FlashArray NFS datastores, we extended that same philosophy all the way up to virtual machines. VM files are exposed as managed directories and files within our native file system, giving us per‑VM visibility for metrics and space usage and a clean mapping between “VMDK file + byte ranges” and internal allocation structures. Without UNMAP, freed space inside a VMDK would remain logically allocated and effectively trapped in that VM, even on a platform that prefers a shared pool. With VAAI‑NAS UNMAP, those freed regions are explicitly marked and returned to the common pool, so free space is not locked inside individual VMs but flows back into the same global capacity reservoir that serves every datastore and workload on the array.

The VAAI-NAS path also supports batched offset/length pairs for UNMAP to keep the protocol overhead and array work under control, even when the guest filesystem is trimming many small regions. On the array side, we coalesce and validate those ranges against the current file layout and then invoke internal deallocation logic in a way that preserves data integrity, maintains the performance characteristics expected of Tier‑1 VMware datastores, and plays nicely with snapshots, replication, and quotas.

Benefits for customers and partners

From a customer and partner point of view, the value of VAAI‑NAS UNMAP for NFS datastores is straightforward and material.

First, it delivers better space efficiency with far less stranded capacity. Logical deletions in the guest now translate to real space reclamation on FlashArray. Thin‑provisioned NFS datastores behave much more like their VMFS/vVol counterparts, and over time, this reduces the “dead weight” carried by large NFS datastores, the frequency and urgency of datastore expansions, and overall usable‑to‑raw capacity ratios for NFS‑heavy VMware environments.

Second, it reduces operational overhead compared to zero‑fill workarounds. Administrators no longer need to schedule periodic “space cleanup” jobs that rewrite large portions of the VMDK with zeros, create IOPS spikes that impact other workloads, and consume network bandwidth and data reduction resources for no business value. Instead, UNMAP becomes just another part of normal guest filesystem hygiene, with the array doing efficient reclamation under the covers.

Third, it creates a more consistent experience across datastore types. For virtualization admins and cloud architects, VMFS, vVols, and NFS on FlashArray all support efficient UNMAP‑style reclamation, so the choice between NFS datastores and block can be made on architectural preference and ecosystem fit, not because of an UNMAP capability gap. That, in turn, reinforces NFS datastores on FlashArray as a serious option for Tier‑1 VMware workloads.

The VMware + Everpure collaboration story

This feature is the result of a multi‑year engineering partnership between VMware (now Broadcom) and Everpure.

We started with a concrete customer problem: space reclamation on thin‑provisioned VMware NFS datastores. Our proposal was to extend the existing VAAI-NAS infrastructure with an UNMAP primitive rather than invent a proprietary side channel. Together with VMware engineering, we refined the VAAI-NAS UNMAP and GET_UNMAP_GRANULARITY semantics, prototyped and iterated on both the ESXi plugin behavior and FlashArray backend handling, and ran extensive scale, performance, and torture testing across thousands of VMs and hundreds of datastores to validate correctness and endurance.

The result is a capability that feels native to VMware admins because it’s enabled through the familiar VAAI-NAS plugin model, exploits the FlashArray system’s strengths in unified block and file architecture, data reduction, and fine‑grained file‑level control, and is implemented as an open, documented extension of VAAI‑NAS, not a one‑off hack.

Closing thoughts

NFS datastores are a significant portion of the VMware storage landscape, and for many customers, they’re the preferred way to build large, flexible virtual infrastructure footprints. Historically, the lack of a clean UNMAP story on NFS has been one of the last functional gaps versus block.

With UNMAP for VMware NFS datastores on FlashArray, that gap closes. Customers gain more efficient, more predictable capacity behavior on their NFS datastores. VMware and Everpure together have delivered the first‑in‑industry, standards‑aligned capability that extends the reach of VAAI‑NAS in a meaningful way.

If you’re already running NFS datastores on FlashArray—or considering a migration from other platforms—this is a great moment to revisit what NFS can do for your VMware estate when you pair FlashArray, VAAI-NAS, and Everpure file architecture together.