Independent Storage Scaling with Google Cloud NetApp Volumes NFS Datastores for Google Cloud VMware Engine

sajith

Overview

Google Cloud VMware Engine gives you a familiar vSphere environment in Google Cloud. As VM estates grow, storage often becomes the bottleneck — and the cost driver. Adding ESXi nodes just to get more datastore capacity is rarely the most efficient answer.

With Google Cloud NetApp Volumes Flex Unified, you can provision NFS volumes from a storage pool and mount them as external NFS datastores on VMware Engine. Storage scales independently from compute. You keep ONTAP data services — snapshots, clones, and replication — behind the volume. And the same Flex Unified pool can also serve other file and block workloads when you need them.

This blog walks you through the basics of using Google Cloud NetApp Volumes Flex Unified to provision an NFS volume and mount it as an external NFS datastore on VMware Engine. It works with bothzonalandregionalFlex Unified storage pools.

We'll use a zonal Flex Unified storage pool with the NFS volume mounted to a VMware Engine private cloud. The same approach works with both zonal and regional storage pools.

Prerequisites

Before you begin, make sure you have:

• An active Google Cloud VMware Engine private cloud with at least one cluster.
• A Flex Unified storage pool already created in the same zone or region as that private cloud.

IAM permissions, VPC peering, the NFS service subnet, volume creation, and datastore mount are covered in the steps below.

Important notes before you start

1. Enable delete protection when you create the volume

Flex Unified volumes used as VMware Engine datastores must be created with delete protection enabled. In the Google Cloud console, this appears as below.

If you use the gcloud CLI, enable delete protection at volume creation with --restricted-actions=DELETE. This prevents accidental deletion while the volume is mounted and in use. This setting is permanent, so enable it when you provision the volume.

2. Volume deletion requires a 52-hour wait after unmount

Even after you unmount the NFS datastore from your VMware Engine cluster, the underlying NetApp Volumes NFS volume cannot be deleted immediately. All clients must first disconnect, and then you must wait more than 52 hours before deletion is allowed.

If you try to delete the volume earlier than this, you will see an error like below.

Plan for this waiting period in migration and decommission runbooks. If you need capacity right after unmount, create a new volume rather than expecting the old one to be removable immediately.

Architecture at a glance

Google Cloud VMware Engine runs your vSphere estate in a private cloud. Google Cloud NetApp Volumes hosts the NFS volumes that you mount as external datastores. Those environments are connected by VPC network peering, so ESXi hosts can reach the NFS service over private IP addresses — without sending datastore traffic over the public internet.

In a typical setup:

• Your customer VPC is peered to both VMware Engine and NetApp Volumes (for management and workload connectivity).
• The VMware Engine network is also peered directly to the NetApp Volumes tenant network. This is the path NFS datastore mounts depend on.
• Optionally, cross-region replication can protect NetApp Volumes data for DR.

NFS datastore traffic uses a dedicated service subnet on the private cloud. After peering is active, allow time for route propagation to ESXi hosts before you mount the datastore.

Step-by-step walkthrough

In this blog, we'll walk through the end-to-end process of connecting Google Cloud VMware Engine to an NFS volume from a Google Cloud NetApp Volumes Flex Unified storage pool and presenting it as an NFS datastore to the VMware Engine private cloud cluster. Along the way, you'll configure the required networking, provision the NFS storage, create the datastore, and mount it to your VMware cluster so it can be used for virtual machine workloads.

What we'll cover:

1. Grant IAM permissions to the VMware Engine service agentEnable VMware Engine to access the Google Cloud resources required for datastore integration.
2. Retrieve Google Cloud NetApp Volumes networking detailsGather the service networking information required to establish connectivity between the two services.
3. Create VPC Network PeeringConnect the VMware Engine network to the Google Cloud NetApp Volumes service network, allowing ESXi hosts to reach the NFS datastore.
4. Configure the NFS service subnetSet up the dedicated subnet that carries NFS traffic between your VMware Engine private cloud and Google Cloud NetApp Volumes.
5. Create a Flex Unified NFS volumeProvision the NFS volume that will be used as the datastore and enable delete protection to safeguard against accidental deletion.
6. Identify the target private cloud and clusterLocate the Google Cloud VMware Engine private cloud and cluster where the datastore will be mounted.
7. Create the VMware Engine datastoreRegister the NFS volume as a datastore within Google Cloud VMware Engine.
8. Mount the datastore to the clusterMake the datastore available to all ESXi hosts in the target cluster.
9. Validate the deploymentVerify that the datastore is mounted successfully and ready to host virtual machine workloads.

By the end of this blog, you'll have a Google Cloud NetApp Volumes Flex Unified NFS volume mounted as a datastore in Google Cloud VMware Engine, enabling storage to scale independently from compute resources and providing a flexible foundation for VMware workloads in Google Cloud.

Step 1: Grant IAM permissions

VMware Engine uses a Google-managed service account to access NetApp Volumes and view network peerings. Grant the roles roles/netapp.viewer and roles/compute.networkViewer to service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com.

Grant the required roles.

Replace PROJECT_NAME and PROJECT_NUMBERwith the value for your environment.

Step 2: Get Google Cloud NetApp Volumes VPC details

To peer VMware Engine with NetApp Volumes, you need the NetApp tenant project ID and tenant VPC network name.

Using the Google Cloud console:

1. Go to VPC networks in the project where NetApp Volumes is deployed.
2. Open the VPC network peered with NetApp Volumes.
3. Open the VPC network peering tab.
4. Select the peering to the NetApp Volumes tenant project (typically named sn-netapp-prod).
5. Copy the Peered project ID and Peered VPC network information. 

You'll need these values in the next step.

Step 3: Create VPC peering between VMware Engine and NetApp Volumes

Before a Google Cloud NetApp Volumes NFS volume can be mounted as a datastore, the Google Cloud VMware Engine private cloud must be able to reach the Google Cloud NetApp Volumes service network.VPC network peeringprovides that connectivity by exchanging routes between the VMware Engine network and the NetApp tenant network, so ESXi hosts can access the NFS export over private IP addresses.

Without this peering, ESXi hosts cannot reach the NetApp Volumes NFS endpoint, and the datastore mount will fail.

Console steps

1. Go to VMware Engine → VPC Network peerings → Create
2. Name: gcve-gcnv-peering
3. VMware Engine network: In current project → select default (or the VEN attached to your private cloud)
4. Peered VPC type: Google Cloud NetApp Volumes
5. Google Cloud NetApp Volumes tenant project ID: the peered project ID from Step 2
6. Route exchange: Enable Import custom routes and Export custom routes
7. Click Create and wait until status is ACTIVE

Verify the peering is active.

Note: The peering connection may become ACTIVE within a few minutes, but route propagation to ESXi hosts can take up to 20 minutes. Wait for propagation to complete before you create and mount the datastore.

Legacy VMware Engine networks: If your private cloud was created before November 12, 2023, you may need a private connection instead of VPC network peering. See Use Google Cloud NetApp Volumes as a vSphere Datastore in VMware Engine for legacy network instructions.

Step 4: Configure the NFS service subnet

NFS datastore traffic between VMware Engine private cloud and Google Cloud NetApp Volumes uses a dedicated service subnet on the private cloud. This subnet must:

• Use a unique CIDR range (at least /26; larger is fine)
• Provide enough IP addresses for each ESXi node in the cluster
• Be used only for NFS datastore traffic (the same subnet can back multiple NFS datastores)

Management and service subnets are created with the private cloud. User-defined service subnets (for example, service-1 through service-5) can be assigned a CIDR when you’re ready to use them for NFS.

Assign a CIDR to the service subnet. In this example, we configure a service subnet named service-1 with 10.20.11.0/24.

Console steps

Go to VMware Engine → Subnets, select your private cloud, and confirm or edit the service subnet you’ll use for NFS.

You’ll use this CIDR in the NFS volume export policy and this subnet name (service-1) when you mount the datastore.

Tip: NSX-T gateway and distributed firewall rules do not apply to service subnets. Keep the CIDR dedicated to NFS datastore traffic and free of overlaps with other networks.

Step 5: Create the Flex Unified NFS volume

Create the NFS volume from your Flex Unified storage pool with delete protection enabled. Include the service subnet CIDR in the export policy:

The export policy must allow:

• The service subnet CIDR (10.20.11.0/24)
• Read/write access
• Root access
• NFSv3 (VMware Engine supports NFSv3 only for external datastores)

Important: The export policy allowed-clients CIDR must match the service subnet you will use at mount time.

Step 6: Identify your private cloud and cluster

Before creating the NFS datastore, identify the ESXi cluster that is part of your VMware Engine private cloud. You will need the cluster name in subsequent steps.

In this example, the cluster name is cluster01. Use this value in the remaining configuration steps.

Step 7: Create the VMware Engine datastore

Create a datastore object that points to your Flex Unified NFS volume. This registers the volume with VMware Engine.

Datastore creation is asynchronous. Verify it is active.

Step 8: Mount the datastore to the cluster

Mount the datastore to your vSphere cluster using the dedicated NFS service subnet from Step 4.

This is what makes the NetApp Volumes NFS volume available to ESXi hosts.

Step 9: Verify the mount

Confirm the datastore is mounted on the cluster and visible to ESXi hosts.

At this point, the NFS datastore should be visible in vCenter under Storage on all ESXi hosts in cluster01.

From vCenter:

1. Open Storage and select gcnvnfsds
2. Go to Configure → Device Backing
3. Confirm:

• Server: matches the NFS IP address of the NetApp volume
• Folder: matches the share name of the NetApp volume

You can now provision VMs to it or migrate workloads with Storage vMotion.

Unmounting and deleting a volume

When you decommission a datastore:

1. Unmount the datastore from the VMware Engine cluster.
2. Confirm no clients remain connected to the NFS volume.
3. Wait for more than 52 hours.
4. Delete the volume if it is no longer needed.

Attempting deletion before the waiting period completes, or while clients are still connected, returns an error.

Why this matters

VMware estates on Google Cloud don’t have to scale storage and compute together. With Flex Unified NFS volumes on Google Cloud NetApp Volumes, you can:

• Add external vSphere datastores without provisioning more ESXi nodes.
• Scale capacity and performance independently for VM workloads.
• Use the same Flex Unified pool for NFS datastores and other file or block workloads.
• Apply ONTAP data services — snapshots, clones, and replication behind your VMware storage.
• Support both zonal and regional storage pool designs.

For supplemental datastores, dev/test environments, tier-2/3 workloads, and storage-heavy VM estates, NFS datastores on VMware Engine are a practical way to bring enterprise NetApp storage to your vSphere environment in Google Cloud.

Get Started

• Ensure you have a Flex Unified storage pool in the same zone or region as your VMware Engine private cloud.
• Follow the steps above — IAM, peering, service subnet, volume, datastore, and mount.
• Review the Google Cloud NetApp Volumes documentation and VMware Engine NFS datastore guide.
• Talk to your NetApp or Google Cloud account team for sizing and architecture guidance.

We can't wait to see how you put Flex Unified NFS datastores to work on Google Cloud VMware Engine.