NFS Datastores overview

VMware Engine lets you use external Network File System (NFS) Datastores to scale storage independently of compute resources.

VMware Engine vSAN provides high-performance virtual storage for VMs running in VMware Engine, and is ideal for Tier-1 workloads. To provide a virtual infrastructure for VMware VMs, the VMware Engine service uses hardware nodes with local NVMe solid-state drives (SSDs) that vSAN manages. If you want to scale only the storage resources in your cluster, you must purchase an entire node, including compute and networking capabilities you might not need. This limitation of vSAN-based hyper-converged infrastructure (HCI) creates demand to scale storage independent of other resources.

With support for external NFS Datastores, VMware Engine lets you scale storage independently of computing resources for your VMware workloads. External NFS Datastores offer a cost-effective solution for Tier-2 and Tier-3 applications, backup and archival repositories, and other storage-intensive workloads that don't require the performance of vSAN.

Supported NFS storage services

You can use external NFS Datastores with the following Google Cloud services:

General prerequisites to using NFS Datastores with VMware Engine

Before you mount an external NFS volume as a Datastore, you must meet the following prerequisites:

NFS Volume requirements

NFS volumes must meet the following requirements:

  • Location: The NFS volume (Filestore instance or Google Cloud NetApp Volumes volume) and the VMware Engine cluster must reside in the same Google Cloud region. VMware Engine doesn't support mounting Datastores across different regions. For stretched private clouds, only regional Datastores are supported.
  • Protocol: VMware Engine supports only NFS version 3 (NFSv3) for use as a VMware Engine Datastore. NFSv4.1 is not supported.
  • Delete protection: If using Filestore or Google Cloud NetApp Volumes, you must enable delete protection on the volume to prevent accidental deletion and data loss.

VMware Engine service agent permissions

To create and mount a Datastore backed by Filestore or Google Cloud NetApp Volumes, VMware Engine uses a Google-managed service agent (service-{project-number}@) to access NFS resources. This service agent requires the following IAM roles:

  • roles/compute.networkViewer: To view compute network peerings for all Datastore types.
  • roles/file.viewer: Required for Datastores backed by Filestore.
  • roles/netapp.viewer: Required for Datastores backed by Google Cloud NetApp Volumes.

Service subnet requirements

You must have a dedicated service subnet with a unique CIDR range allocated for NFS traffic between ESXi hosts and the NFS volume. You configure the service subnet as follows:

  • You must configure a CIDR range for the service subnet that has enough IP addresses to assign one to each node in the private cloud.
  • You can only use the service subnet for NFS Datastore traffic, but you can connect the same subnet to multiple different NFS Datastores.
  • You must add the reserved CIDR allocation for the service subnet to the allowed clients list or export policy of your NFS volume. For Filestore, add an access control rule for the service subnet CIDR range. For Google Cloud NetApp Volumes, add the CIDR to the Allowed Clients section of the volume's export rules.

NSX-T gateway and distributed firewall rules don't apply to service subnets.

Network connection requirements

An active connection must exist between the NFS volume's VPC network and the VMware Engine network (VEN) of the private cloud where you will mount the Datastore. Network charges resulting from storage access within a region don't apply when using Filestore with Private Service Access (PSA).

When connecting to network file services, use one of the following connection methods, depending on your private cloud's VEN type:

  • Standard VEN: Private clouds created in a standard VEN use VPC Network Peering to connect to network file services like Filestore (using PSA) or Google Cloud NetApp Volumes.
  • Legacy VEN: Private clouds that operate on a legacy VEN require a private connection to connect with network file services. If you delete a private connection while an NFS Datastore is in use, it will disrupt access to the Datastore. Therefore, ensure you don't delete a private connection while an NFS Datastore is mounted and in use.

Interoperability with private cloud Lifecycle

NFS Datastores managed by the VMware Engine API remain persistent across private cloud lifecycle events in the following ways:

  • Cluster expansion and contraction: If you add nodes to a cluster with mounted NFS Datastores, VMware Engine automatically mounts those Datastores on the new nodes. If you remove nodes when contracting a cluster, their vmknic IP addresses are released.
  • Node reboot: The NFS Datastore configuration on a node is persistent and remains intact after a node reboot.
  • Software upgrades: NFS Datastores mounted on hosts are unaffected by ESXi, vCenter, and NSX-T component upgrades.

Migration from legacy NFS Datastore mounts

If you created NFS Datastores in VMware Engine before January 1, 2026, you're using the legacy model. To transition to the supported and recommended model, contact Cloud Customer Care to begin the migration process.

Known issues

The following are known issues with external NFS Datastores:

  • During private cloud soft deletion, the network path to the Datastore is severed.
  • After VPC Network Peering is established, route propagation to vSphere nodes can take up to 20 minutes.
  • For Google Cloud NetApp Volumes Datastores, SnapMirror functionality to and from on-premises for disaster recovery is not supported.

What's next