What's New in Nutanix 7.6

The 7.6 release train, which Nutanix labels NCI 7.6, brings Prism Central pc.7.6, AOS 7.6, AHV 11.2 and the 7.6 Flow components. Read as a list it looks like four unrelated backlogs shipping together. Read as a whole, one move repeats in each: something that used to be implied by where it lived becomes an explicit property you assign. That is what makes this release worth planning rather than scheduling.

Projects become the ownership boundary for infrastructure

Projects are not new, and neither is the Internal Project from the pc.2022.6 refactor. What changes is the weight the construct carries, enough that Nutanix now calls this iteration Projects 2.0, and the change only makes sense against how tenant separation worked before it.

Until 7.5 a project covered workloads, users and quotas, and stopped at the infrastructure underneath. Everything below that line was separated by convention: you prefixed categories with a tenant code, built access control policies around those prefixes, and wrote the rules down so the next engineer would not undo them. It works, and it degrades the first time somebody is in a hurry, because nothing in the system knows that the convention exists.

From 7.6 the model itself carries the boundary. Project assignment becomes mandatory for every entity, and anything unassigned is migrated into the Default Project during the upgrade. That migration is permanent and does not roll back, which makes the project structure a decision to take before the window rather than a cleanup afterwards. The scope also widens: a project now owns catalog entities, volume groups, VM policies, Flow Virtual Networking entities and Flow Network Security entities, with tasks and alerts mapped automatically to the project of the object they describe.

Underneath sits a construct worth knowing by name. Allocating physical capacity to a tenant has always meant telling that tenant something about your infrastructure, because clusters and storage containers are named things a project admin can see. The Nutanix resource group closes that gap. It is a set of placement targets, each one an AHV cluster plus a selected set of its non-system storage containers, attached one per project. Infrastructure admins add and remove physical capacity underneath while project users consume it without ever seeing a cluster name, which is the logical-to-physical separation multitenant designs have had to improvise until now.

Categories are where the old convention actually lived. A category key was globally unique, so two customers could not both own Environment with a value of Production, and the tenant prefix in every key was a requirement rather than a style choice. In pc.7.6 categories move to a one-to-one association with a project and the uniqueness constraint disappears. That single change removes the practical ceiling on how many customers fit under one Prism Central.

Tenant networking gets a boundary and the plumbing to use it

Network Controller 7.6 extends project association to VPCs, subnets, gateways, route tables, floating IPs and BGP sessions, with the system enforcing that a tenant touches only its own scope. Sharing is deliberately conservative in this first release: VPCs, route tables and routing policies share across projects, while gateways, VPN connections, BGP sessions and floating IPs stay exclusive to their owner project in pc.7.6, and an overlay subnet shares only when it lives in the Default Project. The conservative default is the right one to start from, since an ownership model that leaks is worse than one that makes you ask.

The connectivity work reads like a list of retired workarounds, and each one removes a compromise that used to land on the customer. A VPC can now attach up to four external no-NAT networks with per-network filtering of the externally routable prefixes it advertises, so a tenant that needs the corporate network and the internet through separate routing domains gets them because it needs them, not because you built a transit VPC around a limit of two. DHCP relay lets an overlay subnet forward requests to the DHCP server the customer already runs, which means moving onto an overlay stops requiring them to hand address management over to the built-in service. An overlay subnet can be disconnected from the VPC routing table while its VMs keep vNICs, addresses and intra-subnet Layer 2 reachability, with BGP withdrawing and readvertising the route automatically, so a staged disaster recovery cutover can park a subnet instead of deleting and rebuilding it. VTEP gateways gain an active-backup pair sharing one service IP, with anti-affinity across hosts, which matters because a stretched Layer 2 segment is what you lean on during a migration and until now a single gateway VM could take it down mid-cutover. Flow CNI supports multiple VPCs per Kubernetes cluster, so pod networks for different namespaces stop sharing one blast radius. Jumphost VMs are now supported across VPC and VLAN subnets, convenient for operators and worth an explicit design decision in a multitenant estate, since a VM that reaches into several tenant networks is a boundary crossing you chose rather than one you inherited.

On the security side, Flow Network Security Next-Gen 7.6 accepts fully qualified domain names as policy sources and destinations, resolving them to IPv4 addresses through the configured DNS and ignoring IPv6, which finally lets a policy target endpoints whose addresses are not yours to pin down. The Kubernetes integration collapses onboarding into one step and auto-detects service IPs, ports and load balancer addresses when programming policy, removing the class of outage where a policy silently stops matching because a service moved.

The Flow control plane finally has a brownfield path

Standalone mode arrived in pc.7.5, but in practice it was a greenfield choice. You picked Standalone or Integrated when you enabled Flow, and if you already ran Integrated you stayed there. On Extra-Large Prism Central instances, where the Network Controller is enabled by default in Integrated mode, that meant most existing estates had no route to the decoupled architecture at all.

The reason to want that route is worth stating, because Integrated mode is not broken. In Integrated mode the Flow components run inside the Prism Central VMs, which means they consume Prism Central resources, their availability is bounded by Prism Central availability, and the only way to give them more headroom is to make Prism Central bigger. For a small estate that is a fair trade. For a provider running tenant networking as a service, it means the component programming the data path and the component rendering the console fail together, which is a coupling nobody would design on purpose.

FEAT-18314 changes that. From pc.7.6 you can migrate the Flow control plane from Integrated with Prism Central to Standalone, where the Flow Controller runs in a Service Microservices Platform cluster on a dedicated AHV cluster, either the one hosting Prism Central or any other cluster that instance manages. The transition moves all Flow configuration out of Prism Central while Prism Central keeps management and orchestration.

Two things to plan for. The documented direction is one way, from Integrated to Standalone, so treat it as a decision rather than a toggle. And if you already run the Flow Controller, upgrading Prism Central to pc.7.6 takes it to 7.5.9 automatically, not 7.6: reaching 7.6 is a manual upgrade through LCM, documented under Upgrading the Flow Controller in the Flow Management Reference Guide.

What the release notes do not describe is the behaviour of existing traffic while the migration runs. A control plane moving should not disturb a data path already programmed on the hosts, but that is an inference rather than a documented guarantee, and it is the first thing worth measuring in a lab before proposing the migration to a production tenant.

Flow modes now diverge in both directions

Once migration exists, the mode stops being something you set at install time and forget. It becomes a choice with consequences, and in 7.6 those consequences point both ways rather than favouring the newer option.

Today the rule-centric policy model and the new Flows and Rules analytics dashboards are documented for Standalone only, while the Kubernetes enhancements and the new scale limits of 100,000 rules per Prism Central and 40,000 address groups are documented for Integrated. Neither list contains the other. In practice that means you cannot pick the mode from the footprint alone: an estate that leans on Kubernetes policy has a reason to stay Integrated today, and an estate that wants rule-level visibility has a reason to move. The decision belongs to design review, and it is worth revisiting each release while the two lists are still converging.

External storage moves from special case to supported shape

HCI remains the reference model, and nothing here deprecates it. What changes is that a compute cluster on an external array stops being a constrained exception. AOS 7.6 adds Dell PowerStore over NVMe over TCP, moves attach and manage workflows into Prism Central instead of Prism Element only, and extends Nutanix Disaster Recovery to PowerStore-backed compute clusters including synchronous replication, Metro and cross-cluster live migration. That last one is what turns the option into something you can put in front of a customer, since an architecture without a disaster recovery story is a lab exercise whatever its merits.

The detail that matters is Compute Cluster High Availability, and it needs the normal case stated first. In a hyperconverged cluster the services that keep the cluster itself alive run on the nodes, alongside the data they manage. That coupling is the point of HCI and it works, but it means the number of nodes you can lose is bounded by what those services need to stay up: past a certain point you do not lose capacity, you lose the cluster. On a compute cluster the data already lives on the array, so the coupling buys nothing and costs the same. From 7.6, cluster service data sits on dedicated volumes on the connected array and the surviving nodes resume the services without intervention, up to the simultaneous loss of N-2 nodes. The property that changed is not where the blocks live. It is that cluster state stopped being a function of node survival.

Native change block tracking offload to Everpure FlashArray follows the same logic. Until now Nutanix kept the change record in metadata volumes it provisioned itself, consuming vDisk budget on every cluster whether or not anyone was backing up. When the array tracks the changes natively those volumes disappear and the maximum number of vDisks per cluster roughly doubles. It requires Purity 6.11.7, and it is worth checking before sizing anything on the old number.

AHV 11.2 and the node that is no longer interchangeable

AHV 11.2 supports NVIDIA HGX H200 and B200 in passthrough with up to eight SXM GPUs per node, adds topology-aware scheduling across NUMA and NVSwitch, and ships system-defined VM profiles for AI workloads. The consequence is not the benchmark. A cluster stops being a pool of interchangeable nodes: where a VM lands now determines whether it gets the memory locality and the GPU interconnect it was sized for. Capacity planning that assumes fungibility gives the wrong answer, and the VM profile becomes the place where that non-fungibility is written down instead of remembered.

Resilience follows the same logic of explicit choice. The 1N&1D configuration now extends beyond three nodes with in-place conversion from Prism Central, and a new 1N/2D configuration lets node and disk resiliency be chosen independently, so the overhead matches the failure you are actually worried about instead of the bundle you were offered. Strict rack-awareness turns best-effort cross-rack placement into a guarantee, at the cost of NCI Ultimate licensing and a minimum of three racks on low-latency links, which is the difference between a rack failure being survivable by design and survivable by luck.

The two-node cluster stops being a dead end as well. Until now growing from two nodes to three on AHV meant rebuilding the cluster, which turned an initial sizing choice for a branch or edge site into a permanent one. From 7.6 you add a node and the cluster becomes a three-node cluster, which is a small change in the release notes and a large one for anyone who starts customers small and grows them.

Security posture becomes state instead of procedure

Hardening a platform has traditionally meant applying a set of changes and then documenting that you applied them. The document is not the system, so the two drift, and proving the posture of a cluster a year later means going back and checking rather than looking.

Security Profiles replace that with a setting. Platform security settings are grouped into Standard, Elevated and Strict tiers applied from the Security Dashboard, with Standard the default on new clusters, so the posture of a cluster is a value you read rather than a history you reconstruct. The operational detail to internalize is that changing the profile on an active cluster starts a rolling restart of the nodes. That makes a tier change a maintenance event, which in turn means the tier belongs in the service description at onboarding rather than in a hardening ticket six months later.

The surrounding changes point the same way. Secure Access replaces direct bash for the admin user with the NuService Menu, a restricted shell, and adds a Support-only Login mode requiring a token exchange with Nutanix Support that grants a 72-hour window, which turns privileged access from something an operator has into something an operator requests. External SSH to AHV hosts is off by default and the host is reached through the Controller VM, shrinking the number of directly reachable privileged endpoints. The Controller VM and Prism Central VM move to a RHEL 9 base aligned with the RHEL 9 STIG, which matters mainly because it lets you point an auditor at a published baseline instead of a vendor assertion.

Upgrade considerations

The constraints in this release are mostly about sequencing, and they are cheap to satisfy in advance and expensive to discover halfway through a window.

• Prism Element clusters need AOS 7.0.1.9 minimum for pc.7.6, and fresh pc.7.6 deployments require AOS 7.6.
• Nutanix Kubernetes Engine is not compatible with pc.7.6. Migrate to Nutanix Kubernetes Platform first.
• Legacy Flow Network Security blocks the Prism Central upgrade entirely.
• Prism Central pc.7.6 does not carry the Flow Virtual Networking features with it. Network Controller and Network Gateway 7.6 take pc.7.6 as a prerequisite and upgrade separately through LCM, so multiple external networks, DHCP relay, disconnected subnets and VTEP high availability appear only after that step. The documented order is LCM first, then Prism Central, then AHV, then the Flow components.
• LCM runs configuration checks before the upgrade and stops if it finds cross-project relationships that will not survive the migration, such as a VM attached to a subnet that belongs to a different project. Worth resolving these before the window rather than during it, and KB-21479 covers the resolution.
• Prism Central on Hyper-V is no longer supported.
• From pc.2024.3.x, run the backup scripts first. The upgrade deletes certain audit logs and Marketplace icons.
• Decide the project structure before the upgrade. Entity migration does not roll back.
• Unlicensed clusters now lose functionality over time. Check lab and staging estates before they go quiet.

Where these features fit in real architectures

Nothing here changes the shape of a Nutanix deployment. What changes is how much of a design has to live in someone’s head. A tenant boundary held together by naming discipline degrades the first time somebody is in a hurry, while one the entity model enforces degrades only when the model changes. That is the trade running through the whole release: more to decide up front, much less to reconstruct later.