Cloning large virtual machines, deploying them from templates, or provisioning capacity for new workloads can quickly consume host resources and saturate the data storage network.

As you are surely aware, NFS had its limitations when it came to virtualization, but now, thanks to implementing VAAI integration in Open-E JovianDSS Up32, we have a smart solution for that. VMware’s vStorage APIs for Array Integration (VAAI) were created to solve exactly this problem by offloading certain storage-intensive tasks from ESXi hosts to the storage array itself.

By supporting VAAI, Open-E JovianDSS can now use it to enhance NFS-based data storage systems, closing the gap with block storage and strengthening its role in VMware virtualization. When those offloads are available over NFS, they can significantly improve how your VMware environment uses Open-E JovianDSS as a shared storage backend.

In this context, a “VAAI primitive” is a low-level storage command that VMware ESXi can send to the storage system. Instead of the host copying data or reserving space on its own, it issues a specific primitive, and the array executes that operation internally. In other words, a primitive is a small, well-defined storage operation that both VMware and the data storage system understand and can accelerate.

Offloaded VM Cloning with Full File Clone

What Full File Clone Does

When you clone a virtual machine or deploy one from a template stored on an NFS datastore, ESXi usually has to read the entire virtual disk file from the datastore and write a new copy back to the same datastore or another one. This consumes CPU, network bandwidth, and time on the host.

With the Full File Clone primitive, the process changes:

  • The ESXi host sends a VAAI Full File Clone command to Open-E JovianDSS, identifying the source file and the desired destination.
  • Open-E JovianDSS performs the copy locally inside the storage system, without streaming all data through the host.
  • When the operation completes, the ESXi host sees a new VMDK on the NFS datastore that is ready to power on as a new virtual machine.

    Benefits in Day-to-Day Operations

    From VMware’s perspective, it is still a standard clone or deployment operation. The difference is that the low-level cloning work is carried out by the storage array rather than the host.

    Using Full File Clone with Open-E JovianDSS provides several practical advantages for daily operations:

    • Faster VM cloning and deployment. Since the data is copied internally on the array, clones and deployments, especially of larger virtual machines, typically complete more quickly than traditional host-based copies.
    • Lower load on ESXi hosts. CPU, memory, and network I/O on the ESXi hosts are freed up for running workloads instead of moving large amounts of data back and forth to storage.
    • More efficient use of network bandwidth. Because the actual data transfer happens within the storage system, NFS traffic related to cloning is significantly reduced.

      These benefits are particularly noticeable in environments where:

      • There are many templates used for frequent VM deployments.
      • Large VMs need to be cloned regularly, for example, for staging or testing.
      • Network bandwidth between ESXi hosts and the storage system is limited or heavily utilized.

        What Full File Clone Does Not Change

        It is important to understand where Full File Clone applies and where it does not:

        • Storage vMotion still uses VMware’s own data movers. The Full File Clone primitive does not accelerate Storage vMotion operations.
        • Snapshot-based or linked-clone style workflows remain handled through standard VMware mechanisms. The NFS VAAI plugin for Open-E JovianDSS does not provide the Native Snapshot Support or Fast File Clone primitives at this time.

          In other words, Full File Clone makes full-file cloning on NFS faster and more efficient, but it does not change how Storage vMotion or snapshot-driven operations are processed.

          Reserve Space: Thick Provisioning for NFS Datastores

          What Reserve Space Does

          NFS datastores are often associated with thin provisioning, where disk space is consumed gradually as data is written. Thin provisioning is flexible and space-efficient, but in heavily oversubscribed environments, it can create a risk of running out of physical capacity if growth is not monitored closely.

          The Reserve Space NAS VAAI primitive addresses this by enabling thick provisioning on NFS datastores:

          1. When you create or reconfigure a virtual disk as thick-provisioned on an NFS datastore, ESXi can issue a VAAI Reserve Space command.
          2. Open-E JovianDSS responds by pre-allocating the full size of that virtual disk on the underlying storage volume.
          3. From that point on, the requested capacity is physically reserved for that VMDK within the storage system.

          This behavior makes thick-provisioned virtual disks on NFS behave much more like thick-provisioned disks on block-based datastores.

          Why Reserve Space Matters

          Reserve Space with Open-E JovianDSS is useful in several scenarios:

          • Critical workloads that must not fail due to insufficient storage capacity can have their space reserved upfront, reducing the risk of “out of space” events.
          • Workloads that require predictable performance can benefit from capacity that is fully allocated, helping avoid some of the contention and fragmentation patterns that may appear in aggressively thin-provisioned environments.
          • Mixed environments that use thin provisioning broadly can still create islands of guaranteed capacity for especially important virtual machines.

            The key advantages include:

            • Reduced risk of running out of space for important VMs, because capacity for thick-provisioned disks is allocated immediately.
            • More predictable performance and behavior for applications that should not compete for thin-provisioned capacity.
            • Per-VM flexibility, since thin- and thick-provisioning can be mixed on the same NFS datastore depending on workload requirements.

              In practice, this means you can use thin provisioning for test, development, and noncritical workloads, while using Reserve Space for databases, key infrastructure servers, and latency-sensitive applications that need guaranteed capacity.

              Conclusion

              By supporting the Full File Clone and Reserve Space NAS VAAI primitives over NFS, Open-E JovianDSS brings two of the most impactful VAAI capabilities into VMware environments that use NFS datastores.

              Together, these capabilities help:

              1. Shorten provisioning and cloning times.
              2. Improve the efficiency of host resource usage.
              3. Strengthen planning and control over storage consumption on NFS datastores.

              When combined with the robustness and flexibility of Open-E JovianDSS, NFS VAAI support becomes a powerful component for building fast, efficient, and predictable VMware infrastructures.

              Janusz Bak

              Chief Technology Officer

              Janusz Bak joined Open-E in 1999 and has been serving as Open-E's CTO ever since. Janusz has over 30 years of software engineering experience and is a recognized expert on storage technologies. Before Open-E, Janusz headed up German support operations at Aztech Systems and at Mega.

              Leave a Comment