Hyperconverged infrastructure ships compute and storage in the same box, and for most workloads that is exactly what you want. The trouble starts when the two axes grow at different rates. You add nodes to get more IOPS you do not need, or you buy capacity and inherit CPU cores that sit idle. Nutanix Cloud Platform with Dell PowerStore breaks that coupling. The compute tier runs AOS and AHV on industry standard servers with no local data disks, and it consumes an external Dell PowerStore array over NVMe/TCP. You size and grow each tier on its own.
This is a two tier, disaggregated design. A single PowerStore array can serve several NCI compute clusters, and a compute cluster can scale without touching a single drive on the storage side. What follows walks the architecture, the hard requirements, the deployment sequence, and the day to day operations, with the practitioner gates called out where they matter. Everything here maps to the NCP with Dell PowerStore 7.6 material.
Architecture: what you are actually building
Two components carry the whole solution. The NCI compute cluster runs Nutanix AOS and AHV on standard servers. It hosts your guest VMs, and it delivers the parts you expect from Nutanix: VM availability, security and microsegmentation through Nutanix Flow, disaster recovery, and lifecycle management through Prism Central. The cluster holds no local data disks. Every AOS vDisk is a volume that lives on the array.
The Dell PowerStore array is the dedicated storage tier. It presents volumes over NVMe/TCP, serves as the endpoint for that traffic from the hosts and Controller VMs, and answers authenticated REST API calls from PowerStore Manager for discovery, host mapping, and data copy operations. Because it runs independently of the compute layer, you scale storage without affecting compute capacity, and the reverse.
The vocabulary you need
A handful of terms carry the design. The NCI compute cluster is the compute construct built from supported standard servers. The Controller VM (CVM) is the AOS storage engine that runs on every node and handles user I/O, data placement, and metadata. Nutanix Foundation Central images the nodes and creates the cluster. On the storage side, PowerStoreOS is the container based operating system on the array, a volume is the block level device presented to hosts over FC, iSCSI, or NVMe-oF, and NVMe over TCP is the transport that carries array access across a standard TCP fabric.
Requirements: the floor before you start
Compute node minimums are firm. Each node needs at least 64 GB RAM, four physical network ports spread across at least two NICs, and a boot controller on the Nutanix hardware compatibility list with 960 GB usable in RAID1. Networking has to be 10 Gb end to end from the compute cluster to the array, sized for the performance you actually need, with MTU 9000 as an optional but recommended setting.
Foundation Central carves a fixed slice out of each node for the CVM: 16 logical cores, 16 physical cores per socket, and 32 GiB of vRAM. The host CPU has to carry at least as many physical cores in a single NUMA node as the CVM needs logical cores, so plan the socket layout with that in mind.
WATCH, CVM sizing. The 16 logical core requirement has to fit inside one NUMA node. If your CPU has fewer than 16 physical cores per socket, the CVM allocation crosses NUMA boundaries and you lose the locality the storage path depends on. Verify core per socket counts before you buy.
On the storage side the setup supports the PowerStore T and later block families. The following models are called out as supported:
- PowerStore 500T, 1000T, 1200T, 3000T, 5000T, 7000T, 9000T
- PowerStore 3200T/Q, 5200T/Q, 9200T
- PowerStore 1500, 5500, 9500
BLOCKER, single appliance only. Configure the PowerStore as a single appliance cluster. Multi appliance clusters are not supported, and you must not expand a single appliance cluster into a multi appliance one while it backs Nutanix. This is an architectural constraint, not a preference. Plan capacity within one appliance from day one.
Software compatibility
The integration pins specific versions together. Treat this as a set, not a menu, and confirm the current numbers against the Nutanix portal before you image anything, since point releases move.
| Component | Version |
|---|---|
| AOS | 7.6 |
| AHV | 11.2 |
| Foundation Central | 2.2 |
| Prism Central | 7.6 |
| Nutanix Move | 6.3.0 |
| PowerStoreOS | 5.0.0.2 or higher |
What the solution does not do
The exclusions matter as much as the requirements, because each one is a design decision you cannot walk back later:
- No one node or two node compute clusters, in production or anywhere else. The floor is three nodes.
- No Repair Host Boot Disk workflow in Prism Element.
- No layered products. NDB, NUS, and NDK are out.
- No RDMA and no iSER for external storage service segmentation.
- No container capacity reservation when you configure external storage.
Network: segmentation and the switch layout
Storage traffic gets its own path. The reference topology connects the compute nodes to the array through two redundant switch fabrics using four VLANs for storage. On each node, the default virtual switch vs0 carries management, live migration, DR replication, and application traffic on Eth0 and Eth2. A separate switch vs1 carries data traffic only on Eth1 and Eth3. IPMI stays on its own out of band path.
Network segmentation is configured from Prism Element only. Nutanix recommends LACP on the switch ports that carry storage, and jumbo frames on the physical ports between the cluster and the array. The vs1 switch is optional but recommended, and it wants at least two physical NICs.
BLOCKER, the 192.168.5.0/24 overlap. Do not assign storage addresses from a subnet that overlaps 192.168.5.0/24. AOS uses an internal virtual switch on that range on the default VLAN to talk between the CVM and the hypervisor. An overlap breaks that path. If you truly need that space, put it on a different VLAN. This one silently wrecks clusters that otherwise look healthy.
When you build the internal interface for external storage you provide a descriptive name, the compute cluster VLAN ID, the storage virtual switch, and an IP pool with a start and end address. Size that pool with headroom. Nutanix recommends provisioning it for up to 32 nodes so future growth does not force a rework. Each host draws one address from the pool, and you add at least as many addresses to the range as you have nodes.
Deploy: the sequence, in order
Deployment is strictly sequential. Do not improvise the order, because two of these steps have hard dependencies on the ones before them.
- Stand up the PowerStore infrastructure. Create the cluster with the Initial Configuration Wizard, set the management network, and build two dedicated NVMe over TCP storage networks, one per fabric, mapped to different front end ports on both nodes.
- Download AOS and AHV and image the nodes. Pull the packages from the Nutanix portal and image the compute nodes with Foundation Central.
- Create the NCI compute cluster from the imaged nodes, in standalone or managed mode.
- Create the internal interface for network segmentation so storage traffic is isolated to the array.
- Attach the PowerStore array to the compute cluster as external storage.
- Install Prism Central to manage the cluster and to manage external storage for other registered clusters.
BLOCKER, external storage comes first. After the cluster is up, configure external storage before you create any storage container or VM. The AHV boot disks cannot hold VM data, so the system prompts you to set up external storage first and refuses container or VM creation until you do. Create a container or VM early and the operation fails outright.
Building the internal interface
In Prism Element, go to Settings > Network > Network Configuration, open the Internal Interfaces tab, and choose Create New Interface. On the interface details, give it a descriptive name such as External Storage LAN, enter the VLAN ID that is already live on the physical switch, and pick the storage virtual switch. Create an IP pool with a netmask and one or more ranges, adding at least one address per node.
On the feature selection step, turn on the External Storage toggle to isolate the traffic, then set the MTU. The field accepts 1280 to 9000, and Nutanix recommends 9000 for PowerStore. Leave it blank and the system falls back to 1500. If the array sits on a subnet that is not reachable at layer 2, use the advanced settings to supply both destination subnets and a gateway, since the CVM then has to route to reach it. Save, then enable.
WATCH, interface build time. Creating the internal interface takes three to eight minutes depending on cluster size. You cannot attach external storage until that task finishes, so build this in before you plan the attach window rather than watching a spinner during a cutover.
Attaching the array
You can attach from either Prism Element or Prism Central. In Prism Element the flow is Storage > Attach External Storage, then Initial Setup, Connection Details, and Storage Details. Select Dell PowerStore as the vendor, give the cluster IP or FQDN of the array, and supply credentials for an account with at least Storage Operator permissions. Name the external storage entity and attach. PowerStore exposes the full array rather than a carved out slice, so there is no sub section to select.
From Prism Central, the path is the Infrastructure app, then Storage > External Storage > Attach External Storage. The compute cluster has to run AOS 7.6 or later, and if the array is on a separate data network you enable network segmentation before you attach. The name accepts up to 75 characters and allows letters, numbers, periods, hyphens, underscores, and the hash character.
WATCH, two hours of red is normal. After the attach, the Health and Cluster Resiliency indicators sit at Critical for roughly two hours, then settle to Healthy. Do not open a ticket or start pulling the deployment apart during that window. It is expected behavior, not a fault.
BLOCKER, two rules you cannot break. You can attach exactly one external storage device to the compute cluster. You can update it, but you cannot delete it, so get the connection details right. And never delete, map, unmap, or modify any PowerStore volume whose name begins with the
nx-prefix. Those belong to Nutanix. Touching them corrupts the cluster.
Operate: availability, upgrades, and the ground rule
Because VM data lives on the array in its own availability domain, VM availability is bounded by surviving compute and array reachability, not by a fault tolerance level inside the cluster. That changes the failure math. An N node cluster tolerates the simultaneous failure of up to N minus 3 nodes, which is to say three nodes have to keep running. Cluster service data sits on dedicated volumes on the array, so after a multi node failure the cluster resumes services on the surviving nodes without hand holding. By default a node retries I/O until the array answers, and you can set a per VM force shutdown timeout to restart affected VMs on a node that still has a path to storage.
Software and firmware split cleanly
Software and firmware take different tracks. Use Nutanix LCM to update AOS and AHV on the compute nodes without downtime. LCM does not handle server firmware and BIOS. For Dell Private Cloud managed servers, use the Dell Automation Platform. For everything else on the compute HCL, including Dell PowerEdge servers that DPC does not manage, upgrade firmware and BIOS by hand: place the node in Nutanix maintenance mode, run the vendor tools, exit maintenance mode, wait for the cluster to report healthy, then move to the next node.
BLOCKER, manage through Prism, never the array. Perform every user action through Prism Central or Prism Element. Do not use PowerStore Manager to modify volumes. The Nutanix control plane owns the volume lifecycle here, and out of band changes on the array put the two views out of sync in ways that are painful to untangle.
Migrating in from ESXi
For existing ESXi and PowerStore estates, you migrate to AHV with Nutanix Move. Move handles ESXi to AHV, but note the constraint that shapes your cutover plan: it supports offline migration only. There is no online path, so every workload takes a maintenance window.
Limits: numbers worth keeping nearby
Two scale ceilings govern the design. The AOS side caps what the cluster can present, and the PowerStore side caps what the array can hold. Size against both.
| Limit | Value |
|---|---|
| Containers per cluster | 256 |
| Size per vDisk | 256 TB |
| vDisks per cluster | 5000 |
| Volume groups per cluster | 2000 |
| Metric | 500 | 1200 | 3200 | 5200 | 9200 |
|---|---|---|---|---|---|
| Volumes and clones per appliance | 1500 | 6000 | 10000 | 16000 | 32000 |
| Max volume size (TB) | 256 | 256 | 256 | 256 | 256 |
| Volume mappings per appliance | 24000 | 40000 | 60000 | 64000 | 96000 |
| Snapshots per volume or clone | 256 | 512 | 512 | 512 | 512 |
| Block volume snapshots per appliance | 50000 | 150000 | 200000 | 250000 | 350000 |
These PowerStore figures shift across releases and the table does not cover every model, so confirm the current numbers in the Dell PowerStore support matrix before you commit a design to them.
Close: when this design earns its keep
Disaggregation is not free. You take on a second management surface, a storage fabric to design, and a set of gates that punish improvisation. What you get back is the ability to grow compute and storage on their own clocks, to keep an existing PowerStore investment in play under Nutanix management, and to run AHV with Flow, DR, and Prism Central over storage that is already sized for NVMe. If your compute and capacity curves have drifted apart, that trade is worth making. If they track each other, standard hyperconverged is still the simpler answer.
The through line across every section above is the same: the gates are not suggestions. Three nodes minimum, single appliance PowerStore, external storage before any VM, stay off the nx- volumes, and drive everything through Prism. Get those right and the rest is a clean, sequential build.
Reference: Nutanix Cloud Platform with Dell PowerStore Deployment Guide, NCP with Dell PowerStore 7.6. Version numbers and configuration maximums move between releases; verify against the Nutanix portal and the Dell PowerStore support matrix before you build.
Leave a Reply