Why the Tenant Exists Before the Control Plane

Multitenancy on Nutanix is a control plane problem, and the primitives were in the platform long before anything shipped to compose them. That argument opened this series, and the architecture piece that followed put a number on what composing them costs: one three-node cluster for the management domain, at least one more for the first application domain, six nodes sized and protected before the first tenant onboards. SP Central, the Nutanix control plane built for service providers, reached general availability on 12 August 2026, and that number did not move.

Most providers do not start there. They start with one cluster, two or three customers already under contract, and a control plane budget that has to wait for the next deal to close. The useful question is not how to shrink the reference architecture until it fits. It is narrower and more practical: which decisions taken on that first cluster survive the day the reference architecture finally arrives, and which ones quietly commit you to a rebuild. The answer is more encouraging than the six-node floor suggests, because the tenant exists well before the control plane that industrializes it.

The Tenant Is a Project

When you onboard a tenant, SP Central creates a project on the selected Prism Central instance and names it after the tenant. Not a new object type, not a hidden construct, not a wrapper around something proprietary. A project, the same one that has been in Prism Central for years and that version 7.6, pc.7.6 in the release strings and from here on, rebuilt for exactly this purpose. Everything the tenant owns lives inside it, and everything SP Central adds sits above it: a dedicated login URL, a tenant-scoped identity provider, an onboarding workflow, a lifecycle.

That single fact turns the SP Central onboarding prerequisites into something more useful than a checklist. Read them forward, they tell you what to prepare before clicking Create Tenant. Read them backward, they tell you what a tenant is made of, and the list contains nothing you cannot build today on one cluster. You need domains available to host tenants. You need clusters identified inside the target Prism Central instance, with capacity to spare. You need dedicated storage containers created for the tenant on those clusters. You need an overlay external network, the Flow construct that carries a tenant’s traffic in and out of its virtual private cloud, ready for each tenant before you configure external connectivity. You need a unique SAML identity provider per tenant, because reusing one across tenants risks privilege leaks.

Storage container, network, identity, capacity boundary. That is the tenant. SP Central does not create those things for you, it consumes them and gives them a lifecycle. A provider who has built them by hand for three customers on one cluster has not built a prototype to be discarded. They have built the object, and what is missing is the machinery that stamps out the next fifty.

What pc.7.6 Changed

The reason this works better in 2026 than it would have in 2024 is that pc.7.6 moved three things from convention into the product.

The first is the Nutanix resource group, an abstracted physical layer that binds a project to the infrastructure it may consume. Each project supports one resource group, and each resource group targets AHV clusters and a selected subset of their storage containers, excluding system-defined containers and anything on replication factor 1. The tenant-to-container mapping that used to be a naming discipline enforced by whoever remembered it is now an object with rules. If you build a project today and give it a resource group, you are building the same binding SP Central will populate.

The second is project-scoped categories. Until pc.7.6, category keys and values were globally unique across the Prism Central instance, which is a reasonable design for one enterprise and a slow-motion problem for a provider with thirty customers who all want a category called environment with a value called production. Categories are now associated one to one with a project, and the global uniqueness constraint is gone. Two tenants can carry identical key-value pairs without collision, which means tenant security policies can finally be written in the tenant’s own vocabulary rather than in a namespace you invented to keep them apart.

The third is not a feature but a requirement, and it is the one that changes hiring and process rather than architecture. Projects require an external Active Directory, LDAP, or SAML identity provider to import members. Local system accounts are not supported in project memberships. Federation is not an improvement you schedule for the quarter after the first customer signs. Without it you do not have a tenant, you have a folder.

Decisions With No Path Back

Most decisions on a first cluster are reversible. Prism Central resizes. Clusters get added. Quotas get raised. The decisions worth agonizing over are the ones with no path back, and they are scattered across five separate documents with no page that gathers them. Four of them are worth real thought before the first node is imaged.

Choosing the Flow Deployment Mode

A fresh Prism Central makes a one-way choice between the Integrated and Standalone deployment modes for Flow, with no migration path from one to the other afterward. Standalone moves the network control plane onto a cluster of its own, which is the resilient answer and also the expensive one, since the Flow Controller deployment is five virtual machines sized to match the Prism Central instance plus a terabyte of shared storage. Integrated keeps everything in Prism Central and fits a first cluster.

The reason this is less frightening than it sounds is that the decision is per instance, not per environment. Every Prism Central you add later is a fresh install and a fresh choice, which means the pragmatic path is available: Integrated on the collapsed first instance, Standalone on the workload instance the day it appears. What you cannot do is change your mind about the instance in front of you.

Why Tenant Networks Start as Overlays

Tenants are overlay-only, and tenant administrators have no access to the virtual switch layer. That is the same property that keeps the tenant boundary clean, since a tenant that cannot reach the switch cannot reach anything the provider did not route to it deliberately. The consequence is direct: a multitenancy built today on VLAN-backed subnets carries nothing forward, because the construct a tenant is allowed to own is a virtual private cloud and its overlay subnets.

This is the door most likely to be walked through by accident, because VLAN-backed networking is what everyone already runs and it works perfectly well for two customers. It stops working as a foundation on the day the tenant needs to own its own address space, and that day arrives before SP Central does.

Nothing Gets Created Outside a Project

Anything created outside a project lands in the internal Default Project, which carries full infrastructure access and whose migrated shared entities remain visible to everyone. The rule is not that the Default Project stays empty, because it will not: it is the provider’s own space, and SP Central expects it to be, to the point that the external connectivity workflow lists only transit VPCs belonging to the default project. The rule is that nothing tenant-owned gets created there. The virtual machine someone spins up just to test something is the one found two years later attached to a subnet three tenants can see.

Nutanix enforces a version of this discipline at upgrade time. Life Cycle Manager health checks stop the upgrade to the new project construct when they find invalid cross-project relationships, such as a virtual machine attached to a subnet owned by a different project, and the migration itself is permanent with no rollback. A sloppy layout is not cosmetic debt. It is a blocked upgrade, discovered on the evening you planned to do the upgrade.

Quotas Belong to the Policy Engine

Legacy quotas were discontinued in pc.2024.1, and the move to policy engine quotas is irreversible. There is no reason to start anywhere else, and one reason to be deliberate about it: the quota mechanism today is documented as best effort and fail open, which makes it an excellent governance signal and a poor contractual ceiling. Build the commercial model on top of it knowing that, rather than discovering it after the first invoice is contested.

Three smaller constraints belong on the same sheet without needing a section each. Tenant names in SP Central are immutable, between three and twenty-eight characters, and become public subdomains under a dedicated fully qualified domain name, so the project naming convention chosen casually today is a hostname later. Projects workflows use the v4 APIs exclusively, and mixing v3 and v4 produces undefined behavior including missing resource group configuration. Resource groups support AHV clusters only.

Growing One Separation at a Time

With the doors handled, growth is a sequence of additions, and none of them touches the tenants.

One cluster, collapsed. Management and workload share the same three nodes. One Prism Central, one project per tenant with its resource group, one virtual private cloud and one overlay external network per tenant, one identity realm per tenant on an identity provider you run or the customer’s own.

Two clusters. The second becomes the workload cluster and the first keeps the control plane. Same Prism Central, same projects, no migration. This is already the shape of an application domain, with the single difference that one Prism Central instance is still doing both jobs.

A second Prism Central. The workload instance appears next to the management instance, both running on the management cluster, and Flow gets enabled only on the workload side. Because this is a fresh instance, the one-way Flow decision is available again and free. The image catalog does not fork either: from pc.7.6, a Content Repository on the management instance can act as the source the new instance subscribes to, receiving a read-only, synchronized copy of the provider’s golden images instead of a hand-maintained duplicate.

Nutanix Central and SP Central. The control plane arrives last, into a topology that already matches it.

Sizing follows the same logic, and it is worth reading the tables for what they actually say rather than for the headline numbers. Extra-Small is not a small Prism Central, it is a different profile: no quotas, which removes the entire resource control model for tenants. Small looks sufficient on paper at twenty-five clusters and two hundred projects, until portfolio services cut the cluster ceiling to ten and the optional features start eating into twenty-eight gigabytes of memory. Large, at ten vCPU and forty-six gigabytes for fifty clusters and five hundred projects, is where a provider starts.

The interesting row is Extra-Large, and the interesting part is not its size. Its cluster and project limits are identical to Large. What it buys is stated in parentheses in the table: preallocated resources for the Advanced Network Controller service. Extra-Large is Large with the network control plane budget already set aside, which makes the choice between them a question about where Flow runs rather than a question about scale. Optional features never increase scalability, they consume it, and this row is the clearest illustration of that principle in the entire document set.

Then there is the requirement that explains itself once you see who it protects: SP Central expects at least one Prism Central instance deployed as three virtual machines in Large or Extra-Large sizing. That is not a capacity number, since a single Large instance already covers fifty clusters. It is a resiliency number for the instance that faces customers. A single Prism Central going down is an internal inconvenience when it is yours and a service level breach when it is theirs.

Where the Collapse Shows

One caveat belongs in plain view rather than in a footnote. In the reference architecture the management cluster runs no tenant workloads, and that separation is what guarantees platform operations cannot touch tenant virtual machines and tenants cannot reach management services. On a single collapsed cluster you do not have that guarantee by hardware. You have it by network and by project, which is weaker and worth naming as such.

What that means concretely: the isolation you can still enforce is real. Projects scope role-based access, quotas, categories, and the resource group. Flow keeps tenant traffic inside per-tenant virtual private clouds with no path to the management network except the one you build. What you lose is the physical failure boundary, and you compensate for it with the network design that the transit models piece covers.

There is one specific reason not to treat this loosely. The SP Central documentation warns that the Alerts page can expose the Prism Central address to tenant administrators, and instructs administrators to ensure the Prism Central instance is not reachable from tenant networks, validating routing domain access lists and firewall rules. On a collapsed cluster that instruction is not a hardening step you get to postpone. It is the only thing standing where a cluster boundary would otherwise be.

The One Thing Without a Rollback

The shape of the argument is that almost everything scales by addition. Prism Central resizes, clusters join, quotas move, instances multiply, and the control plane installs into a topology you already have. What does not scale by addition is the discipline inside the project, because the project is the tenant, and the project construct is the one place in this design where the platform tells you plainly that the migration is permanent and there is no way back.

A provider with three customers on one cluster and clean projects is closer to a Nutanix service provider practice than a provider with twelve nodes and a habit of creating virtual machines outside projects. The hardware gap closes with a purchase order. The other one does not.