Proxmox for MSPs: Multi-Tenancy, RBAC and Client Isolation

Broadcom has shut the door on most VMware cloud service providers. Here is how to build a multi-tenant hosting practice on Proxmox VE: what the platform gives you natively, where the gaps are, and how to close them.

---

The forcing function: there is no small-MSP path left at VMware

For managed service providers, 2026 did not bring a pricing problem. It brought an existence problem.

Broadcom terminated the VMware Cloud Service Provider partner contracts as of late January 2026, moving to an invitation-only model reserved for a small set of large strategic providers. The White Label model, which had allowed smaller MSPs to deliver VMware services through upstream partners, was sunset before that. The practical consequence: hundreds of regional and mid-sized CSPs, many with a decade or more of VMware practice and loyal customer bases, can no longer purchase licenses for existing customers or onboard new ones. Their options are to route everything through one of the remaining anointed partners, sell their book of business, or change platforms.

That third option is why MSP interest in Proxmox VE has gone from curiosity to migration projects. Proxmox gives service providers something Broadcom just took away: an infrastructure platform whose economics and availability they control. No partner program can be revoked, no SKU can be discontinued under you, and your VMs are standard KVM/QEMU workloads on open formats.

But hosting customers on shared infrastructure is a different discipline from running your own datacenter. Before moving your first tenant, you need clear answers on three things: isolation, delegation, and operational separation. Let us take them in order, looking first at what Proxmox VE provides natively and then at what a service provider has to add.

Pillar 1: Tenant isolation

Isolation questions come in three layers.

Compute. KVM provides hard VM-level isolation; that part is solved by the hypervisor. What Proxmox adds is resource pools: VMs and containers grouped logically, which becomes the foundation for per-customer permissioning. What pools do not do by themselves is enforce consumption limits: a pool is a grouping, not a quota. CPU units, memory limits and cgroup controls exist per guest, but "customer A may use at most 64 vCPU, 256 GB RAM and 10 TB across all their VMs" is not a native construct.

Network. Proxmox SDN has matured into a genuine multi-tenancy tool: zones and VNets let you give each customer isolated L2 segments, with VLAN, VXLAN or EVPN encapsulation depending on your fabric. Combined with the Proxmox firewall at datacenter, node and VM level, you can build real segmentation. The operational gap is at the IP layer: nothing natively tracks which addresses are allocated to which tenant, hands out IPs on VM creation, or prevents an operator from attaching a customer VM to the wrong bridge at 2 a.m.

Storage. Ceph pools or ZFS datasets can be dedicated per tenant for strict separation, though most MSPs run shared pools for efficiency. Shared pools make per-tenant capacity accounting and quota enforcement an application-level concern, because Ceph does not know what a customer is.

Backup. Proxmox Backup Server namespaces are the key primitive: one datastore, logically partitioned per tenant, with API tokens and ACLs scoping each customer to their own namespace. This works well, but wiring it correctly (namespace, token, ACL, PVE storage entry, per customer, without error) is exactly the kind of repetitive privileged task that should never be done by hand at scale.

Pillar 2: Delegation and RBAC

An MSP has at least four classes of humans touching the platform: your senior engineers, your junior operators or outsourced NOC, your customers' own IT staff, and auditors. Proxmox VE's native permission system (users, groups, API tokens, roles, ACL paths on pools) is solid within one cluster. The service provider problems start above the cluster:

• Permissions are per cluster. Ten clusters means ten permission sets to keep in sync, and no single view of "what can this operator touch across the fleet".
• There is no first-class tenant. A customer is a convention (a pool, a naming scheme), not an entity with users, quotas, networks and backups attached to it.
• Audit evidence is scattered. Task logs exist per node and per cluster; producing "everything operator X did on customer Y's infrastructure last quarter" is an archeology project.
• Identity should be centralized. Your operators should authenticate against your IdP with MFA, with roles derived from groups, and no local password fallback that bypasses SSO.

Whatever tooling you choose, insist on these properties: fleet-wide roles with scoped delegation, IdP integration (OIDC or LDAP) with enforced MFA, no local-credential bypass on SSO accounts, and an audit trail in a real database rather than log files.

Pillar 3: Operational separation

The layer that determines whether your margins survive. Every tenant needs their own backup policy and restore path, their own alerting scope, their own consumption reporting for billing, and, if you sell anything self-service, their own portal that shows their resources and nothing else. Ideally, all of it is branded as your service, not as a stack of open-source tools.

None of this is a criticism of Proxmox VE: the platform provides the right primitives (pools, SDN, PBS namespaces, ACLs) and deliberately leaves the service provider abstraction to the ecosystem. Which is where we come in.

How ProxCenter turns Proxmox into a hosting platform

ProxCenter's Virtual Datacenter (vDC) module was built precisely for this. A vDC is the missing first-class tenant object: a bundle of resource pools, quotas, networks, backup bindings, users and reports that you hand to a customer.

• Tenant cockpit. Each customer gets a cloud-style view of their vDC: live consumption against quotas for CPU, RAM, storage, snapshots and backups, with no node names, cluster details or other tenants visible anywhere. Per-tenant tree state and pool-filtered data mean a tenant sees a datacenter, not your infrastructure.
• Quota enforcement at every step. Deploy from template, ISO, clone or restore: every path checks the tenant's quotas before acting, and resources outside the tenant's assignment (foreign nodes, storages, bridges) are refused upfront. The 2 a.m. wrong-bridge scenario is structurally prevented.
• Native IPAM. SDN VNets and subnets are managed at the vDC level, with automatic IP and MAC reservation on deploy, clone and restore, plus a scan that adopts externally created VMs into the tenant's pool. Address allocation stops being a spreadsheet.
• Per-tenant PBS, auto-provisioned. Binding a PBS to a vDC automatically creates the namespace, the sub-token, the ACL and the PVE storage entry. Tenants get scoped backup jobs with a structured schedule picker, verify and delete actions, and self-service restore, either overwriting the source or restoring as a new VM into their own pool.
• White-label reporting. Capacity, utilization, inventory, security and compliance reports are generated per tenant with your branding, ready to attach to the monthly invoice. RBAC, OIDC SSO with group mapping, enforced TOTP and the PostgreSQL audit trail cover the delegation pillar across the entire fleet.

The result is that Proxmox VE plus ProxCenter behaves like a hosting platform: your engineers operate clusters, your operators work within scoped roles, and your customers consume virtual datacenters.

Where this is heading: the Cloud Director gap

VMware service providers did not only lose vSphere; many of them lost VMware Cloud Director, the tenant provisioning and self-service layer their entire commercial model ran on. There is currently no complete open-source equivalent, and we think that gap is the single biggest opportunity in the Proxmox ecosystem.

The vDC module you can use today is deliberately the foundation of that answer. The direction for its next major iteration is to close the remaining distance to a full Cloud Director alternative: deeper tenant self-service, richer network services per vDC, and the provisioning workflows a provider needs to onboard a customer without an engineer in the loop. If you are an ex-VCSP evaluating platforms and Cloud Director parity is your bar, talk to us: providers migrating off Cloud Director are exactly who we are building this with.

A pragmatic migration path for ex-VCSP providers

1. Stand up a pilot cluster (3 nodes with Ceph is enough) and wire it into ProxCenter alongside your existing estate.
2. Model one real customer as a vDC: pools, quotas, VNets, PBS namespace, one operator with a scoped role. Validate the isolation with your most paranoid engineer.
3. Migrate that customer's workloads using the built-in migration pipeline (ESXi-direct and vCenter sources, warm migration with changed-block tracking so busy disks move without data loss; XCP-ng, Nutanix and Hyper-V are covered too).
4. Run the billing cycle end to end: consumption report, invoice, restore test, audit extract. If those four artifacts satisfy you, industrialize per wave.
5. Keep your VMware island only if a workload certifies against ESXi alone, and let its size shrink with each renewal.

The window matters: your customers are reading the same Broadcom headlines you are, and the providers who present a credible landing zone first are the ones who keep those customers.

FAQ

Can Proxmox VE do multi-tenancy on its own? The primitives are there: pools, granular ACLs, SDN zones and VNets, PBS namespaces. What is missing natively is the tenant abstraction itself: quotas across a customer's resources, IPAM, automated backup scoping, self-service and per-tenant reporting. That is the layer ProxCenter's vDC module provides.

Is a tenant fully prevented from seeing other tenants? Yes. A vDC tenant sees only their own pools, guests, networks, backups and reports. Nodes, clusters and other tenants do not appear in their interface, and quota enforcement blocks deployment onto resources outside their assignment.

We ran VMware Cloud Director. Is there an equivalent? Not a complete one in the open-source world today. ProxCenter's vDC module covers the core (tenants, quotas, IPAM, scoped backups, white-label reporting, self-service portal) and its roadmap is explicitly aimed at Cloud Director parity. Bring us your Cloud Director feature list and we will map it honestly.

How do we bill customers? Per-tenant utilization and capacity reports give you the consumption data, white-labeled, on a schedule. Invoice generation stays in your PSA or billing system, fed by those numbers.

---

ProxCenter is The Proxmox Datacenter Platform: centralized management, RBAC, audit, compliance, reporting and multi-tenant vDC for Proxmox VE fleets. Evaluating an exit from VMware? Read our TCO analysis and our comparison with vCenter. Start a trial: the only thing we need is your node count.