[Idea] Multi-tenancy enhancements: Support multiple vDCs per tenant & storage policies with QoS / Quota limits

[A1-DS]

Use Case / Context

During our evaluation of ProxCenter, we found that a few key architectural concepts we rely on in VMware Cloud Director are currently missing or enforcing single-instance limits:

1. Multiple vDCs per Tenant: A single tenant/organization can own multiple Organization vDCs allocated across different clusters.
2. Storage Policies & QoS: Storage is assigned via named policies mapped to specific backend datastores, enforcing performance tiers via per-disk IOPS and/or MB/s throughput caps alongside vDC storage quotas (GB/TB).

As we look at adopting ProxCenter, aligning with these Cloud Director patterns is crucial for our multi-cluster operations and tiered storage offerings.

---

Feature Suggestion 1: Lift the 1-vDC-per-Tenant UI Limit

Current Behavior

The UI currently enforces a strict 1-tenant = 1-vDC restriction during vDC creation:

• Selecting a tenant that already has a vDC triggers a warning alert (vdc.tenantHasVdcs) and disables the Cluster/Connection picker.
• Admins cannot submit the form to add a second vDC on another cluster for that tenant.

Technical Observations

The backend appears to be structurally ready to support multiple vDCs per tenant:

• Backend (src/lib/vdc/index.ts): The slug/uniqueness check (Step 2) is already scoped to [tenantId, connectionId, slug].
• Frontend (VdcTab.tsx): computeVdcSlug already appends the cluster slug to differentiate vDC slugs across connections (tenantSlug-clusterSlug).

---

Feature Suggestion 2: Cluster-Level Storage Policies with Disk QoS & Quota Limits

Concept

Introduce Storage Policies configured at the cluster/connection level:

• Map directly to specific backend storage pools (e.g., Ceph, ZFS, LVM-thin).
• Enforce per-disk IOPS limits (Read/Write) and/or Throughput limits (MB/s) when provisioning virtual disks for VMs within a vDC.
• Assign vDC-specific storage quotas (GB/TB) per policy.

Proposed Capabilities

1. Policy Creation: Define named storage policies per cluster (e.g., Gold-NVMe capped at 5000 IOPS, Silver-HDD capped at 1000 IOPS).
2. vDC Assignment & Quotas: Allow admins to assign specific storage policies to a vDC during creation or editing, specifying a dedicated storage quota (GB/TB) for each policy.
3. Automated PVE Throttling: Map policy QoS settings directly to Proxmox VE's native drive bandwidth and IOPS limits (mbps_rd, mbps_wr, iops_rd, iops_wr) upon VM disk creation or updates.

---

Why This Matters

Together, these two capabilities provide an essential foundation for enterprise multi-tenant IaaS management:

• Flexibility: Tenants can seamlessly span multiple clusters with isolated vDCs.
• Fair Allocation & Monetization: Admins can guarantee QoS, prevent "noisy neighbor" issues, and easily monetize different storage performance tiers without manual PVE interventions.

---

Would love to hear your thoughts on these ideas or if any of these items align with the current roadmap!
If you need some more insight or help testing just let me know.

[adminsyspro]

Thanks for the detailed write-up. The pointers into the code made this much quicker to act on, and both suggestions are now implemented.

Suggestion 1, multiple vDCs per tenant. The UI restriction is gone, shipped in v1.4.7. A tenant can own one vDC per cluster, and the app gained a vDC view context so operators and tenant users switch between them, with the inventory, quotas and dashboards following the selection.

Suggestion 2, storage policies with QoS. Implemented in PR #753. A storage policy is a named QoS profile on one shared storage of a connection, carrying optional iops_rd, iops_wr, mbps_rd and mbps_wr caps. A vDC attaches any number of policies, each with its own optional quota in GB, so the same policy can be offered with 100 GB to one tenant and 2 TB to another. The caps are stamped server side on every tenant disk write whatever the client sends: config edit, guest creation, template deploy, clone, move to another storage, resize, restore from backup and snapshot rollback. The last three re-stamp once the Proxmox task settles, since PVE replays the archived or snapshotted drive line verbatim. Per-tier usage is metered from the storage content listing scoped to the vDC pool, so secondary disks count too, and it surfaces as a usage bar per tier in My vDC plus a pre-flight check in the deploy wizard.

Two notes on the model. There is one policy per (connection, storage), because the tier quota is metered per storage and two policies on one storage would make the attribution ambiguous. And detaching a policy from a vDC is refused while its guests still hold volumes on that storage, with the VMIDs named in the error.