A provider can put multiple customers on shared infrastructure long before it has a usable cloud service. The harder problem is giving each tenant its own identity, resource scope, networking, quotas, APIs, and daily operations without giving customers access to the provider management plane or turning every change into a ticket.
Nutanix SP Central 1.0 is aimed at that problem. Nutanix describes it as a self-service interface for operating resources in a multi-tenant IaaS platform. It adds the provider and tenant workflow above Nutanix Central and Prism Central domains while the domains and workload clusters underneath it continue to own the resource objects and execute the workloads.[1][2][10]
The Stack Still Has Layers
SP Central is integrated with Nutanix Central. In SP Central terminology, a Prism Central instance registered beneath Nutanix Central is a domain. When the provider adds a tenant to a domain, SP Central creates a project for that tenant in that Prism Central instance and associates the resources the provider has made available there.[1][2][17]
That hierarchy matters because the products are doing different jobs.
| Layer | What it owns in this design | Why the provider should care |
|---|---|---|
| Nutanix Central and SP Central | Tenant lifecycle, domain assignment, tenant access, onboarding workflow, and cross-domain tenant experience | Gives the provider one tenant model across multiple Prism Central domains. |
| Prism Central domain | Tenant project, project policies and quotas, resource scope, and domain API endpoint | Project state and entity operations remain tied to a specific domain. |
| Workload clusters and Nutanix infrastructure | VM execution, AOS storage, Flow networking, and the physical capacity behind the service | Performance, failure behavior, and capacity still come from the infrastructure selected for the tenant. |
| Tenant portal and APIs | Delegated administration and infrastructure operations within assigned domains | Self-service does not grant ownership of the provider management plane. |
The SP Central 1.0 interoperability table is also specific. The release is documented with AOS 7.6, AHV 11.2, Prism Central pc.7.6, Nutanix Central 2.1, and Nutanix Cloud Manager 2.1.[3] I would qualify the exact build set before deployment rather than assume a nearby version is equivalent just because the UI loads.
Nutanix also documents a reference deployment that separates management and workload clusters. The management side hosts the management components, while tenant VMs run on workload clusters registered to the workload Prism Central instance for that availability zone.[4] A provider can now attach an operational reason to that separation: tenant traffic and tenant failure domains should not become the path to the systems that administer every tenant.
A Tenant Can Span Domains. Its Projects Do Not.
One SP Central tenant can be assigned to more than one Prism Central domain. SP Central creates a separate project for that tenant in each domain, so the tenant can have a common service identity above multiple independent project and capacity scopes.[2][17]
The second domain is not another view of the first project. It has its own project identifier, clusters, storage allocation, network resources, quotas, and entity state. Providers can use domains for availability zones, regions, service tiers, or other placement boundaries, but SP Central does not turn several Prism Central instances into one resource pool.
Architecture point domain assignment is service placement. The selected domain determines which project, infrastructure, capacity, and management endpoint will handle the tenant operation.
The API model makes that boundary explicit. Nutanix documents tenant-scoped v4 APIs that operate across SP Central domains, but VM, image, subnet, VPC, and other entity requests use the FQDN of the allocated domain as the API host. Requests include X-Tenant-Name, and most entity operations also need the project external ID. Nutanix specifically says not to use the generic SP Central tenant URL for those domain-local entity APIs.[10][16]
A portal can make the service look continuous across domains. Automation still needs to know which domain it is talking to.
Onboarding Builds on Provider-Prepared Infrastructure
SP Central tenant onboarding is a composition workflow over infrastructure the provider has already prepared. The provider selects a domain, workload clusters, storage containers, networking, and vCPU, memory, and storage quotas. SP Central then creates the tenant relationship and the corresponding Prism Central project for that domain.[5][6]
The prerequisites are where the service design shows through. Nutanix calls for tenant storage separation, network preparation, quota enforcement on allowed Prism Central domains, and identity planning before the tenant is put into service.[6][13][14] Nutanix also recommends a unique SAML identity provider entity ID for each tenant because reusing an entity ID can create privilege leakage between tenants.[13]
The tenant receives its own SP Central access context, but that does not make the underlying infrastructure generic. The provider still decides which clusters the project can use, which storage belongs to it, which networks can be consumed, and how much capacity the project is allowed to request.
That is the right place to evaluate SP Central. The interesting question is not whether a portal can create a VM. It is whether the provider can turn the same onboarding workflow into a repeatable service across every Prism Central domain without leaving different quota, network, storage, and identity rules behind it.
The Portal Is Not the Enforcement Point
Several of the controls a tenant experiences through SP Central are enforced by components below SP Central. Mapping those controls before go-live is more useful than treating the portal as one large security boundary.
| Tenant-facing control | Where the state or enforcement lives | Provider validation |
|---|---|---|
| Tenant identity and roles | SP Central tenant IAM and configured identity providers | Prove users and roles cannot cross tenant scope. |
| Project membership and quota | Prism Central project and quota enforcement | Verify every allowed domain is prepared and that quota behavior matches the service definition. |
| VM, image, subnet, VPC, and volume operations | Specific Prism Central domain and project context | Test the domain FQDN, tenant header, project ID, and denied requests. |
| Workload execution and storage | AHV/AOS workload infrastructure selected for the project | Measure capacity and failure behavior on the actual clusters and containers. |
| Tenant network isolation | Flow VPCs, subnets, external connectivity, routing, and policy | Test tenant-to-tenant denial and management-plane denial from the data path, not from the portal. |
Quotas are a good example. SP Central exposes vCPU, memory, and storage limits, but Nutanix requires quota enforcement to be configured on every Prism Central instance allowed into SP Central.[14] The SP Central resource documentation also states that project quota limits do not apply to powered off VMs, snapshots, images, or templates.[6]
Those objects can still consume storage and operational headroom. I would not use the three onboarding quota values as the whole capacity or billing model. Provider reporting still needs to account for the stored objects and reserve enough infrastructure for failures, maintenance, and the service commitment being sold.
Storage and networking have the same split. Nutanix requires dedicated storage containers for tenant separation and warns against sharing them between tenants.[6] Flow provides the tenant network constructs, but the provider still owns external connectivity, routing, and the management network around them.[8][9]
The practical design question is simple: for every control the tenant can see, know which lower layer actually enforces it and what happens if that layer is inconsistent in one domain.
Provider-Owned Objects Need Change Control
SP Central creates and depends on objects inside the Prism Central domains it manages. During domain allowlisting, Nutanix documents creation of a service account and authorization policy for communication with the domain and warns administrators not to change or delete those objects.[7] The same workflow documents that an allowed domain cannot simply be removed later.[7]
Project resources have similar ownership rules. Nutanix directs administrators to manage SP Central project resources through the SP Central workflow and documents restrictions around changing generated projects, tenant identity objects, storage assignments, and network sharing from underneath the service.[6][7][9][17]
A Prism Central administrator may have enough privilege to make a direct change. That does not make the change safe for SP Central state. Provider change control should identify which objects are owned by SP Central, which are provider underlay, and which are delegated to the tenant.
Removal deserves the same discipline. SP Central will not remove a tenant project while associated entities remain, and project deletion is permanent.[18] Offboarding therefore needs dependency discovery before somebody treats Delete as a billing-system action.
Management reachability also belongs in acceptance testing. The SP Central documentation warns that tenant-visible alert information can expose Prism Central addressing and directs providers to block tenant reachability to management with routing and firewall controls.[7] The address being visible is not the failure. A tenant network being able to reach the management endpoint is.
Self-Service Still Resolves to a Domain
SP Central gives tenant administrators and tenant consumers different operational scopes. Tenant administrators can manage identity providers, users, roles, categories, and monitoring. Consumers can operate infrastructure only in domains for which they have been granted access, without the same tenant-wide administrative authority.[11][15]
Automation follows the same model. Nutanix requires X-Tenant-Name on tenant-specific API requests. For domain-local entities, the client uses the domain FQDN and normally the project external ID. A missing tenant header fails authentication or permission checks, and the generic tenant URL is not the endpoint for a domain-local VM, image, subnet, or VPC operation.[10]
Operational view I would test the failure cases before approving tenant automation. Remove the tenant header, use a project outside the tenant scope, and send a domain entity request to the wrong endpoint. A successful negative test is evidence that the boundary is being enforced where the design says it is.
Recovery Has More Than One State
The SP Central 1.0 guide includes backup and restore procedures for SP Central state and explicitly separates that workflow from a disaster recovery design.[12] Nutanix Central has its own backup workflow, and Prism Central and workload protection have their own recovery requirements.[19] These are different layers and should stay different in the runbook.
Restoring one management component does not prove the tenant service is back. The recovered service also depends on Nutanix Central, the required Prism Central domains, DNS and certificates, tenant identity, provider networking, the tenant projects, and the workload data beneath them.
I would test recovery from the tenant side. Start with authentication, enumerate the assigned domains, perform a domain-local API call, reach a workload through the expected tenant network, and confirm the provider can still administer the service without opening management access to the tenant. That sequence proves more than a successful control-plane restore command.
What I Would Prove Before the First Tenant
- Release set: Confirm the SP Central 1.0 interoperability matrix against the exact AOS, AHV, Prism Central, Nutanix Central, and NCM builds being deployed.[3]
- Domain readiness: Verify quota enforcement, provider service accounts, authorization policies, capacity, storage, and networking on every Prism Central domain that will accept tenants.[6][7][14]
- Tenant isolation: Prove identity, project, storage, network, and API denial between two tenants, including negative tests from tenant networks toward management endpoints.[6][7][9][10]
- Domain placement: Put the same tenant in two domains and verify that project IDs, capacity, networks, and API endpoints remain domain-specific while the tenant experience stays coherent.[2][10][17]
- Lifecycle discipline: Test onboarding, adding a second domain, resource changes, entity cleanup, project removal, and the administrator change controls around SP Central-owned objects.[5][6][17][18]
- Service recovery: Restore the management state using the documented procedures, then prove tenant authentication, domain discovery, API operations, networking, and workload access as one service.[12]
A service provider should know the answer to those tests before the first customer depends on the platform. A portal demo proves the happy path. The provider needs evidence that the tenancy model still holds when domains differ, users make bad requests, administrators make changes, and a control-plane component has to be recovered.
The Bottom Line
SP Central 1.0 adds a service-provider tenancy layer that ordinary Prism Central operations did not provide by themselves. It gives the provider one place to onboard tenants, assign domains, delegate access, and present self-service across shared Nutanix infrastructure.[1][11]
Prism Central domains still own the projects and domain endpoints. AHV and AOS still run and store the workloads. Flow still carries the network design. SP Central is most useful when those layers are treated as a deliberate service architecture instead of being hidden behind the word portal.
For architects evaluating it, I would spend less time counting the screens SP Central exposes and more time mapping ownership. Know which layer creates the object, which layer enforces the boundary, which endpoint the operation reaches, and which component has to recover when that part of the service fails.
Key Takeaways
- SP Central 1.0 is a service-provider tenancy and self-service layer integrated with Nutanix Central. It does not replace Prism Central, AHV, AOS, or Flow.
- One tenant can span multiple Prism Central domains, but the project and entity state remain specific to each domain.
- Tenant onboarding depends on provider-prepared cluster capacity, storage, networking, identity, and quota enforcement.
- Tenant-facing controls are distributed across SP Central, Prism Central projects, Flow, and the workload infrastructure, so each boundary needs its own validation.
- Recovery has to prove the complete tenant service, not only the restoration of one management component.
Source Notes
Product behavior changes. These sources were checked against public Nutanix documentation available on September 13, 2026.