Multi-Tenancy
Multi-tenancy lets a single ProxCenter instance serve multiple isolated organizations, teams, or customers from one place. Each tenant is isolated, while the provider keeps a single, fleet-wide operational view of every cluster.
ProxCenter supports two tenant operating models, and a tenant is created in one of them. The model decides how that tenant consumes infrastructure and what its users see.
The two operating models
You choose the operating model when you create a tenant, in Settings > Tenants. It is fixed at creation and cannot be changed afterward, so pick it deliberately.
| Operating model | UI label | The tenant owns... | The tenant sees... | Typical use |
|---|---|---|---|---|
| MSP | MSP -- Owns whole clusters and connections | One or more entire Proxmox (and PBS) connections | The full cluster view of its own connections, unmasked | Managed service providers giving each customer their own dedicated cluster |
| vDC (IaaS) | vDC -- Shares clusters via virtual datacenters | A slice of a shared cluster, defined by a virtual datacenter | A masked, vDC-scoped view of a shared cluster | Self-service IaaS where many tenants share the same physical clusters |
The two models can coexist on the same instance: some tenants can own dedicated clusters (MSP) while others share infrastructure through vDCs.
Multi-tenancy is available in the Enterprise edition and requires the multi-tenancy feature in your license. The Tenants tab is visible only to provider administrators.
The provider (NOC) view
There is always one built-in provider tenant (the default tenant). It is the NOC console, and this is the single most common point of confusion:
The provider keeps full, fleet-wide visibility over every connection, no matter which tenant owns it. Assigning a cluster to a tenant does not remove it from the provider's inventory, dashboard, or reports. That is by design: the provider is the single pane of glass across the whole fleet, with each cluster tagged by its owning tenant.
Per-tenant isolation appears in two other ways instead:
- By switching into a tenant with the tenant selector (see Switching tenants).
- Through per-tenant login users, who only ever see their own tenant (see Users and isolation).
So if you have assigned clusters to tenants and "nothing looks different" from your administrator account, that is expected. You are looking at the NOC view. Switch into a tenant, or log in as one of its scoped users, to see the per-tenant experience.
Setting up an MSP tenant
This is the workflow for handing a dedicated cluster to a customer.
- Go to Settings > Tenants with a provider administrator account and click Add Tenant.
- Provide a name, slug, and optional description, and set Operating model to MSP. Remember that the model is immutable after creation.
- Assign the cluster connection(s) to the tenant. By default a connection belongs to the provider pool (the default tenant), so ownership is an explicit choice. You can set it at either of two points:
- At connection creation: when a provider administrator creates a connection, an owner can be selected directly in the connection dialog. Leaving the owner unset keeps the connection in the provider pool.
- Later, from the tenant: for a connection already in the provider pool, edit the MSP tenant and, in the Connections section, pick it under Assign connection, then click Add.
- To take a cluster back, use Release to pool next to the connection in the tenant's owned list. The connection returns to the provider and stays fully operational.
A connection can be owned by only one MSP tenant at a time. Once owned, that whole cluster (its nodes, pools, storages, VMs, and backups) is the tenant's, and the tenant's users get an unmasked full-cluster view of it.
VMID ranges
A tenant can be given a reserved VMID window, so the guests it creates stay inside a numbering range you control. This is optional and off by default, and it works for both operating models: an MSP tenant that owns whole clusters, and a vDC tenant that shares a provider cluster with its neighbours.
Set it in Settings > Tenants: edit the tenant and fill in VMID range (optional) with a First VMID and a Last VMID. The section appears for every tenant that has an operating model, which means every tenant except the built-in provider tenant.
| Rule | Detail |
|---|---|
| Both ends or neither | Fill both fields to set a range, clear both to remove it. One end alone is refused |
| Allowed bounds | Between 100 and 999999999, and the first VMID must be lower than or equal to the last |
| No overlap | A range that intersects another tenant's range is refused, whatever operating model either tenant uses |
| Not on the provider | The provider tenant cannot carry a range. The API refuses one even if the field is forced |
The tenants table carries a VMID range column showing first - last, sorted on the lower bound. A tenant with no range leaves the cell empty.
Once a range is set, every VM and container created through ProxCenter for that tenant takes a VMID inside it. Three flows are checked server-side:
- Creating a VM or a container
- Cloning a guest, on the new VMID
- Deploying from a template, a cloud image, or an ISO
The Generate next available ID button, and the automatic suggestion behind it, return the lowest free VMID in the range. ProxCenter computes it itself rather than asking Proxmox for the next free id, because the Proxmox helper works per cluster and stops well below the high numbering windows an MSP may want to reserve. A VMID that has just been suggested is remembered briefly, so two operators creating a guest at the same time do not receive the same number.
Availability is checked across all of the tenant's PVE clusters, not only the cluster being targeted, so a VMID stays unique across the tenant's whole estate even though Proxmox itself only rejects duplicates inside one cluster. Which clusters those are depends on the operating model:
| Operating model | Clusters scanned |
|---|---|
| MSP | The PVE connections the tenant owns |
| vDC (IaaS) | The provider clusters the tenant's vDCs sit on, resolved through every vDC of the tenant, disabled ones included. Scanning more clusters only makes the uniqueness check stricter |
On a shared cluster the scan reads the whole cluster, so guests belonging to other tenants and to the provider count as taken. That is deliberate: Proxmox VMIDs are cluster-global, and a suggestion that ignored the neighbours would collide the moment it reached Proxmox.
What the tenant sees when a request does not fit:
| Situation | Result |
|---|---|
| VMID outside the range | Refused, with the allowed range shown |
| VMID already used anywhere in the tenant's clusters | Refused as already in use |
| Every VMID in the range is taken | Refused, reporting that no free VMID is left in the range |
| One of the tenant's clusters is unreachable | Refused, because uniqueness cannot be verified |
Enforcement is deliberately relaxed toward the existing estate. Guests that already exist outside the range are never touched, renumbered, or flagged. Only new creations are constrained.
The last case above is a fail-closed behaviour, not a bug: if one of the tenant's clusters cannot be reached, ProxCenter refuses the creation rather than risk handing out a VMID that is already used on the cluster it could not read. Bring the connection back or clear the range to unblock the tenant.
Two flows are not constrained by the range: restoring a backup as a new guest, and choosing the target VMID of a migration. Their dialogs propose an in-range number, but a VMID typed by hand, or supplied through the API, is accepted there. Treat the range as a numbering convention enforced on new guests, not as a hard reservation across every possible entry point.
Ranges do not apply to the provider tenant. On a vDC tenant a range is an addition to the pool and quota boundaries, not a replacement for them: the pool decides what the tenant sees and the quotas decide how much it may consume, while the range only decides the numbers its new guests take.
Extending ranges to vDC tenants needs no upgrade action. The columns backing the feature have existed since v1.4.7, and the restriction to MSP tenants was purely application side. A vDC tenant that had no range before simply has an empty one.
vDC (IaaS) tenants
A vDC tenant does not own a whole cluster. Instead it consumes one or more virtual datacenters, which slice a shared cluster with pools, allowed nodes and storages, networks, quotas, and PBS namespaces.
- Create the tenant with Operating model set to vDC.
- Create or assign the tenant's vDC and configure pool membership, allowed resources, quotas, and backup bindings.
A vDC defines:
- Proxmox pool membership
- Allowed nodes, storages, bridges, VNets, and subnets
- CPU, RAM, storage, snapshot, and backup quotas
- VLAN pools, the ranges of VLAN IDs the tenant may build its own networks in
- Storage policies, the IOPS and bandwidth caps on a given storage plus an optional quota for that tier
- PBS namespace and backup job boundaries
- Datacenter assignment for Green IT metrics
A vDC tenant can hold one vDC per shared cluster, so a tenant that consumes several clusters gets one vDC on each. From the second vDC onward, its users get a vDC switcher in the top navigation bar that narrows the whole interface to one vDC, or aggregates all of them. A tenant with a single vDC sees no switcher and behaves as before.
A vDC tenant can also carry a VMID range, like an MSP tenant. On a cluster shared between several tenants the range keeps each customer's numbering inside its own window, while uniqueness is still verified against every guest on the cluster.
See Virtual Datacenters for the full vDC workflow, including storage policies and tenant VLAN networks.
Switching tenants
Any user who can access more than one tenant gets a Tenant selector in the top-right profile menu. Provider super admins see every enabled tenant there and can switch into any of them.
Switching tenants reloads the application scoped to that tenant immediately:
- Switching into an MSP tenant shows the full-cluster view of only the connections it owns.
- Switching into a vDC tenant shows its sliced, vDC-scoped view.
- Switching back to the provider tenant restores the fleet-wide NOC view.
The selector only appears once you have access to more than one tenant. If you do not see it, confirm that you have created at least one additional tenant and that it is enabled.
Users and isolation
Assign users to a tenant in Settings > Tenants: edit the tenant and use the Users section to add a user. A newly added user receives a default role (Viewer); set the role you actually want from RBAC.
Super admins are pinned to every tenant by design and always see the whole fleet. A super admin cannot be limited to a single tenant, even if you add them to one. For a login you intend to hand to a customer, use a non-super-admin user with a scoped role. That user will only ever see their own tenant.
Data isolation
Tenant boundaries are enforced across shared services. The boundary is the owned connections for MSP tenants, and the vDC pools for vDC tenants:
- Inventory -- Tenant users see only their owned clusters (MSP) or their vDC pool resources (vDC). Provider administrators see the full hierarchy.
- Deployments -- Requests that reference foreign nodes, storages, bridges, VNets, subnets, or pools are rejected. A VLAN tag outside the vDC's pools is rejected the same way.
- Disk QoS and storage tiers -- On a vDC tenant, disks placed on a governed storage carry the policy's IOPS and bandwidth caps, and consumption is metered against that tier's quota.
- Backups -- PBS archives and PVE backup jobs are scoped to the tenant's owned PBS or its vDC pool and namespace.
- Events and Tasks -- Operational activity is filtered by tenant visibility.
- Reports and Alerts -- Generated and displayed within tenant boundaries.
- Audit logs -- Tenant actions remain attributable, while provider administrators can review activity across tenants.
Isolation also applies when several vDC tenants share the same Proxmox node or cluster.
Tenant lifecycle
A tenant is either active or disabled, controlled by the Active toggle in the tenant dialog:
| State | Description |
|---|---|
| Active | Users can log in and use the tenant's resources |
| Disabled | Tenant users lose UI access. Proxmox resources, backups, and IPAM are preserved, and the action is reversible |
Disable a tenant to suspend access for billing, security review, or offboarding while keeping its configuration intact. The default provider tenant cannot be disabled.
Cross-tenant users view
Provider administrators can use the cross-tenant users view to list every user across all tenants on one page, with tenant assignments, role propagation, and account status. This is useful for MSP support teams managing many customer accounts. Tenant administrators only see users within their own tenant scope.
Announcing maintenance to tenants
A provider super administrator can publish a banner at the top of the interface and address it to every user, to selected tenants, or to selected roles, which is the simplest way to announce a maintenance window to customers from one place. The banner is configured in Settings > Broadcast and is documented in Notifications.
Settings visibility
Provider-only settings stay hidden from tenant users. Enterprise tabs such as LDAP, OIDC, white-label, notifications, and platform alerts are shown only when relevant to the current user and license.
Licensing across tenants
In MSP deployments you can stack multiple licenses on one install and attribute coverage to each customer tenant. See Licensing for license stacking, cluster mapping, and the per-tenant rollup.
Permissions
| Permission | Description |
|---|---|
super_admin | Provider-wide access to every tenant and all configuration |
admin.tenants | Create, edit, enable or disable tenants, and assign connections and users |
Tenant management is also provider-only: these actions are available from the provider tenant, not from inside a customer tenant. See RBAC for scoping roles inside a tenant.