Nutanix Cloud Platform with NetApp ONTAP: A Deployment Field Guide

What this is. A field guide for the person who has to stand up a Nutanix compute cluster on AHV that keeps its VM data on NetApp ONTAP over NFSv3. You probably know one side of this well and inherited the other. Version scope: NCP with NetApp ONTAP 7.6.0.50 (AOS 7.6.0.50 and AHV 11.2.0.6, per the installer file names in the Nutanix guide), read next to the NetApp solution pages dated October 28 and November 9, 2026.

What this is not. A replacement for the deployment guide. There are no ONTAP cluster build steps here, no Foundation Central walkthrough, no screenshots, and no performance numbers. Other external storage vendors are out of scope.

On this page

1. What you are building
2. Requirements and the version floor
3. Limits, and which one binds first
4. Network: three segments, one of them unforgiving
5. ONTAP preparation: volumes, exports, and the service account
6. Deployment order and the attach
7. Day two: health states, updates, upgrades
8. Data protection, DR, and what is missing at GA
9. Migration and sizing
10. If you read nothing else

1. What you are building

Two tiers. The NCI compute cluster runs AOS and AHV on standard servers and hosts your VMs. It has no directly attached data storage. The ONTAP cluster holds the VM data and serves it over NFSv3 from a storage virtual machine (SVM). On that SVM, a FlexVol volume is exported as an NFS path, and the Nutanix cluster consumes that path. You grow each tier independently.

Nutanix talks to ONTAP on two channels. The data path is NFSv3. The control plane (VM provisioning, snapshots, clustering logic) is the ONTAP REST API. That split explains most of the prerequisites later: you need a data LIF and an export policy for the first, and a management LIF and a REST role for the second.

“Compute only” does not mean “no AOS”. There is still a Controller VM on every node, and the cluster reaches ONTAP through the AOS storage controller. If you were planning the node count as if the CVM were gone, redo the math with it in. The NetApp sizing page says the same thing: include the CVM resources on every node.

2. Requirements and the version floor

One housekeeping item from the recommendations: before you image the nodes, pull any unsupported or unused components, such as Fibre Channel or InfiniBand HBAs. This design is NFS over Ethernet and nothing else.

The patch level is the requirement. “We are on 9.16.1” is not an answer. The floor is 9.16.1P16. An array on an earlier P release of a listed version does not qualify, and the storage team’s upgrade window is usually the longest lead time item in the project. Ask for the full version string in the first meeting.

3. Limits, and which one binds first

Now put the numbers next to each other. The figures below are calculated from the table above:

• 32 nodes at 128 powered on VMs each is 4,096 VMs.
• 20,000 vDisks spread over 4,096 VMs is about 4.9 vDisks per VM.
• At six vDisks per VM, which is the shape of the validated DR example in the guide, you reach 20,000 vDisks at about 3,333 VMs.
• 20,000 vDisks at two files each is 40,000 files on the array.

Count vDisks, not VMs. In a database heavy or multi disk estate the vDisk ceiling arrives before the VM ceiling. Pull the disk count per VM from your inventory before you commit to a cluster count. More than 20,000 vDisks per cluster is listed as unsupported, not as a soft recommendation.

4. Network: three segments, one of them unforgiving

The CVMs accept NFS traffic only from the designated ONTAP data LIF addresses. LACP is supported and recommended on both the host side and the NetApp side. The NetApp page adds two details: use an interface group as the home port for the NFS LIF, and if LACP is not available, run active/active with MAC pinning on the virtual switch.

The trap: a blank MTU field. When you create the internal interface for external storage, leaving the MTU field empty sets it to 1500. Your switch ports and the ONTAP broadcast domain are at 9000 because you did your homework, and the one field you skipped is the mismatch. Type 9000. Then test with a full size frame, not a default ping.

5. ONTAP preparation: volumes, exports, and the service account

The ONTAP work happens before a single node is imaged. In order: create or pick the SVM, create the management and data LIFs, create the volumes, create the NFS export and export policy, apply the policy at the right level, verify NFS access from the Nutanix storage network, then review capacity, autosize, snapshot, and QoS settings.

Volumes

A data location can be a whole FlexVol, a qtree, or a folder inside either. FlexGroup volumes are not supported for data or for cluster services. The NetApp page adds that the volume must use the UNIX security style, and gives these FlexVol settings:

The service volume (the documents also call it cluster services or metadata) holds internal Nutanix data. A dedicated one is optional and recommended. Size it at a minimum of N TB, where N is the number of nodes: a three node cluster needs at least 3 TB of available capacity for internal Nutanix usage. Calculated: a 32 node cluster needs at least 32 TB. Thin provision it.

The first export path is not like the others. Nutanix recommends a single export path with enough capacity for the data volumes, and caps you at 10 paths per cluster. The first path you add hosts the default storage container. Unless you name a dedicated service path at attach time, it hosts cluster services too. Choose it on purpose.

Export policies

No 0.0.0.0/0 rules. The client match is the CVM address or subnet range. The guide’s security guidance adds the AHV host ranges for data volumes, and keeps the service volume strictly to the CVM IPs, applied at the root of the metadata FlexVol. You can pull the CVM address list from the Prism API or ncli. Two protocol items to hand to the storage team: AUTH_SYS Extended Groups must not be enabled on the SVM, and the data path is NFSv3.

The REST role and service account

The NetApp page gives the CLI for it. Replace the SVM, role, and user names with yours:

security login rest-role create -vserver ntnx-svm -role nim-ntnx-role -api "/api/cluster" -access readonly
security login rest-role create -vserver ntnx-svm -role nim-ntnx-role -api "/api/cluster/jobs" -access readonly
security login rest-role create -vserver ntnx-svm -role nim-ntnx-role -api "/api/network/ip/interfaces" -access readonly
security login rest-role create -vserver ntnx-svm -role nim-ntnx-role -api "/api/storage/file/clone" -access read_create
security login rest-role create -vserver ntnx-svm -role nim-ntnx-role -api "/api/storage/volumes" -access readonly
security login rest-role create -vserver ntnx-svm -role nim-ntnx-role -api "/api/storage/volumes/*/files" -access all
security login create -vserver ntnx-svm -user-or-group-name nim-ntnx-user -application http -authentication-method password -role nim-ntnx-role

The application must be http and the authentication method is password. This is the account you type into Prism at attach time. Do not use the default admin role. Build the custom role above and scope it to the SVM, so the Nutanix cluster can only touch the storage that was allocated to it.

Tell the ransomware feature about the .dt files. If ONTAP Autonomous Ransomware Protection is on, exclude Nutanix .dt files from detection. Nutanix management operations write high entropy .dt files into the NutanixMgmtShare container, and ARP can read that as abnormal activity. The storage team gets a ransomware warning, the virtualization team gets a phone call, and nothing is wrong.

6. Deployment order and the attach

1. Set up ONTAP: SVM, LIFs, volumes, export policies, REST role and account.
2. Download the AOS and AHV installation packages from the Nutanix Support Portal.
3. Set up Foundation Central.
4. Image the nodes and create the NCI compute cluster with Foundation Central.
5. Create the internal interface for the external storage network in Prism Element.
6. Attach ONTAP to the compute cluster from Prism Element.
7. Install Prism Central, after the attach and not before.

The order is not a suggestion. The AHV boot disks cannot hold VM data, so until external storage is attached you cannot create a storage container or a VM. The operation fails. Prism Element prompts you to configure external storage at first login for that reason, and Prism Central is a VM, so it waits too. Container capacity reservation is not supported in this configuration.

Two imaging notes for the Foundation Central step: make sure there is no time skew between the hosts and Foundation Central, and do not assign addresses from a subnet that overlaps 192.168.5.0/24 on the default VLAN. Nutanix KB-7559 gives the reason: every Nutanix cluster, on all AOS versions, uses 192.168.5.0/24 for internal communication between the CVM and the hypervisor, on an internal virtual switch with no physical uplinks. Those packets never leave the host. The catch is that each host and CVM now has a directly connected interface in that range, so neither can reach anything real that lives on an external 192.168.5.0/24 network. If production already uses that subnet and cannot move, the KB lists three ways to coexist: keep the hosts and CVMs in their own VLAN and accept that they cannot reach services there, NAT between the Nutanix management network and that subnet, or separate the two with VRFs. The KB calls VRF the most complicated of the three and says to bring in the network team for either of the last two.

The internal interface

Before you start, remove the uplinks you want for storage from the default virtual switch vs0 and create a separate virtual switch at MTU 9000. Then in Prism Element go to Settings > Network > Network Configuration, open Internal Interfaces, and click Create New Interface. Give it a name, the VLAN ID that already exists on the physical switch, the storage virtual switch, and an IP pool with at least n+1 addresses for n nodes. On Feature Selection, turn on the External Storage toggle and enter the MTU. If the array is not reachable at layer 2, the advanced settings take Destination Subnets and a Gateway, and you must supply both. Save, then click Enable. The task takes three to eight minutes depending on cluster size, and you cannot attach storage until it finishes.

The attach

In Prism Element: Storage, then + Attach External Storage. Three tabs follow.

Four decisions you cannot undo. One: a compute cluster takes exactly one external storage device, and you can update it but never delete it. Two: once network segmentation is enabled for external storage it cannot be disabled, because doing so removes the interface and takes critical cluster services with it. Three: the dedicated service volume path is offered only during the attach. The Advanced Options section is gone afterwards, and you cannot remove a path that hosts cluster services or the default container. Four: do not rename the FlexVol volumes or export paths after setup. Renaming affects VM I/O. Walk into the attach with the path list written down.

Two hours of red is the expected result. After the attach, the Health and Cluster Resiliency / Fault Tolerance Status widgets stay critical for about two hours and then turn green. Put that in the change record so nobody opens a case at minute twenty.

Once Prism Central is installed you can attach and update from there as well: Infrastructure application, Storage > External Storage, Attach External Storage, same three tabs with a cluster selector on the first. Access is governed by three permissions:

7. Day two: health states, updates, upgrades

Prism Element shows the attached storage under Storage > Table > External Storage. The overall status is Healthy only when every host reports Healthy. One unhappy host makes the whole entity Unhealthy, and a host can report several conditions at once.

The Capacity Breakdown tab lists each export with its status (Online or Offline), usage, and the storage containers mapped to it. In Prism Central the same entity can show a third status, Unknown: that means Prism Central is on pc.7.6 while the cluster’s AOS is earlier than 7.6. Upgrade AOS and the status reports correctly.

The Update action changes the name, the management LIF address, the credentials, and lets you add export paths. Upgrades split in two. AOS and AHV go through Life Cycle Manager with no downtime. Server firmware and BIOS do not: LCM does not support them on a compute cluster, so you do them with the server vendor’s tools, one node at a time. Maintenance mode, upgrade, exit maintenance mode, wait for healthy, next node. The guide adds one check that reads like it was written after an incident: confirm the serial number of the node you are flashing matches the one you put in maintenance mode. For support cases, logs are collected with Logbay.

Sources: Nutanix Cloud Platform with NetApp ONTAP Deployment Guide · NCP with NetApp ONTAP 7.6.0.50 · Deploying NCP with NetApp ONTAP: External Storage Tab in Prism Element Web Console, Updating the Attached External Storage Entity, External Storage Page in Prism Central Web Console · Software and Firmware Upgrade Life Cycle Management · Log Collection.

8. Data protection, DR, and what is missing at GA

This is the section to read twice if you are an ONTAP person, because the array features you would reach for first are the ones not integrated yet.

The single most useful thing in this section. A VM snapshot taken in Prism is an ONTAP file clone of each VM disk, not an ONTAP volume snapshot. Per the NetApp page, a file clone is a writable copy in the active file system. It cannot be locked against deletion, it is not an ARP recovery point, and SnapMirror or SnapVault do not retain or vault it independently. Each disk is cloned separately, so a multi disk VM is not captured at one shared point in time unless that is coordinated. If your ransomware recovery plan says “roll back to the immutable snapshot”, that plan does not cover these VMs today.

For DR, the Nutanix guide gives a scale table for bi directional replication with remote recovery points on AOS 7.6.0.50: 4,800 vDisks replicated out per cluster, 4,800 total in replication between two sites, 4,800 per protection policy or recovery plan. The validated example is 800 VMs with six vDisks each per site, which is exactly 4,800 (calculated). Exceed it and the guide warns of recovery point creation failures and the array filling up.

Replication at GA means Nutanix asynchronous DR. It is the only supported replication method in this release, and ONTAP SnapMirror is not available. Set RPO expectations on asynchronous replication.

NetApp describes ONTAP snapshot integration, SnapMirror integration, and Shift toolkit integration with Nutanix Move as planned for a future release, without dates, and suggests that customers who need immutable recovery points or want to standardize DR on ONTAP replication consider waiting. That is a vendor telling you plainly where the edge is. Take it at face value.

9. Migration and sizing

If you already run ESXi on ONTAP, the path to AHV on ONTAP is Nutanix Move, and only Move. The Nutanix guide says online migration of ESXi VMs is not supported and describes Move as a copy based migration (snapshot or CBT) with minimal downtime. Even though the data starts and ends on NetApp storage, it is copied. The NetApp Shift toolkit, which would avoid full copies through ONTAP cloning, is not supported in this release. Plan the cutover windows and the temporary double capacity accordingly.

Sizing splits the same way the architecture does. Compute is sized on the Nutanix side from aggregate CPU and memory, with the CVM reservation counted on every node. Storage is sized on the ONTAP side, and the Nutanix guide’s entire instruction there is to consult your NetApp partner solution engineer. The NetApp sizing page fills in the method:

• Collect 30 to 90 days of VM level data from vCenter: CPU, memory, provisioned and consumed capacity, IOPS, throughput, I/O size, latency, peak periods.
• Use the measured average I/O size. Do not assume 8 KiB or 16 KiB for everything.
• Aggregate IOPS across VMs over common time intervals to find real concurrent peaks. Summing every VM’s individual peak overstates the requirement.
• Pick controllers on IOPS at target latency, throughput, network bandwidth, and failover performance together. IOPS alone does not select a controller.

Sources: Nutanix Cloud Platform with NetApp ONTAP Deployment Guide · NCP with NetApp ONTAP 7.6.0.50 · Migration from ESXi to NCP with NetApp ONTAP Setup · Operation Specifications. NetApp virtualization solutions · Data protection, disaster recovery, migration, and limitations for Nutanix with ONTAP (October 28, 2026) · VM migrations. NetApp virtualization solutions · Size ONTAP storage for Nutanix AHV migrations (October 28, 2026).

10. If you read nothing else

Nutanix, AHV, AOS, Prism, and Nutanix Move are trademarks of Nutanix, Inc. NetApp, ONTAP, FlexVol, FlexClone, FlexGroup, SnapMirror, SnapVault, MetroCluster, and Trident are trademarks of NetApp, Inc. VMware, ESXi, and vCenter are trademarks of their owner. All other names are the property of their respective owners. This is a personal site and nothing here is a statement on behalf of any company.