Support multiple storages per vDC (data + ISO/template + tiers)

[sinocals]

Summary:
Currently a vDC appears to be bloqued with a single storage. This makes several common MSP/IaaS workflows impossible to deliver to tenants. We'd like a vDC to support multiple attached storages, ideally with a role/content type per storage (e.g. images, iso, vztmpl).

Context
We're evaluating ProxCenter Enterprise as a replacement for VMware vCloud Director in a multi-tenant MSP setup (two Proxmox clusters, Ceph-backed, multiple storage tiers). ProxCenter 1.4.5.

Problem
With one storage per vDC, we got those problems:

ISO deployment for tenants is impossible. RBD/Ceph pools only hold images, not files. To let a tenant boot a VM from an ISO, the vDC needs an ISO-capable file storage in addition to its data storage. Since only one storage can be attached, assigning the ISO storage means the tenant loses their data storage, and vice versa. Result, the deploy wizard returns "No ISO-capable storage available in your vDC" and there is no clean workaround (that I'm aware ok). Some of our clients specifically require uploading their own ISOs (custom/legacy OS, appliances) and want to be able to do it by themself.

Second point, no multi-tier storage within a single tenant. Today in our offers, we expose several storage tiers (HDD and SSD pool). With proxcenter, a tenant cannot be offered more than one tier because the vDC is bound to a single storage. This is a significant limitation vs. vCloud Director storage profiles.

Template/cloud-image storage separation. Cloud images and templates ideally live on a shared file/ISO storage, separate from the tenant's data pool. One-storage-per-vDC forces awkward compromises here too.

Would it be possible to allow attaching multiple storages to a single vDC ?
Add a content-type/role per attached storage (images, iso, vztmpl, backup), so the deploy wizard can pick the right target automatically (data disk → images storage, ISO mount → iso storage, etc.).
Keep server-side quota enforcement per storage, consistent with the existing vDC model (maybe propose a quota per storage and not a global storage quota ?).
Ideally, support shared read-only ISO/template storage attachable to multiple vDCs (provider-managed catalog), while data storage stays tenant-isolated.

Why it matters
This single limitation currently forces us into a provider-managed-only model (admin clones/deploys for the tenant) instead of true tenant self-service, and blocks the ISO-upload use case entirely. Multi-storage-per-vDC would unblock both self-service ISO boot and multi-tier storage offerings a core IaaS features when migrating away from vCloud Director.

Happy to provide more detail on our setup or test a preview build.

[adminsyspro]

Thanks for the detailed write-up. This is exactly the kind of MSP/IaaS context that helps us prioritize.

You're right that a vDC is currently bound to a single shared storage, and that this blocks tenant ISO boot, multi-tier offerings, and clean template/cloud-image separation. The single-storage assumption runs through the deploy path and the quota model today, so lifting it is a real piece of work rather than a config toggle, but we agree it is the right direction for a true self-service IaaS story.

We think this is a valuable addition and we are putting it on the roadmap. The direction we are leaning toward matches your suggestions closely:

• Multiple storages attachable to a single vDC, each with a content role (images / iso / vztmpl / backup) so the deploy wizard can auto-target the right one (data disk to the images storage, ISO mount to the iso storage, and so on).
• Server-side quota kept consistent with the vDC model, and we will look at per-storage caps as you propose.
• A provider-managed shared ISO/template catalogue attachable to several vDCs, while data storage stays tenant-isolated.

This overlaps with a broader vDC enhancement we are already tracking in #510 (building a vDC from existing resources, including multiple shared storages), so we will treat multi-storage-per-vDC as part of that effort and cross-reference the two.

We will gladly take you up on the offer to share more about your setup and to test a preview build once we have something to show. Thanks again for the thorough report.