Feature Requests

@stell / @woody - any update on this? It’s been 70+ days since last MP update. I know you guys were all hands on the migration tool, but MP really needs some love, and we have a number of clients wanting to programmatically (via API) be able to spin up machines. Especially in the new AI age, where agents can do this themselves on any other platform, we are really behind because we do not have this yet.

Hi, It would be really nice to be able to share specific templates and ISO to specific tenants. If a reseller has 10 tenants and they want to use a particular template or ISO at present this needs to be uploaded and shared to each tenant (or globally), if they don’t want it to be made globally available then the option to share to just a sub set of tenants would be very handy and save a lot of time and disk space. Regards, Mike

Thanks, Stellios! I’m glad you like the idea. I look forward to hearing from you about it.

Excellent suggestion @miked I’ll get this added to our backlog for sure.

I absolutely agree, and this is something we have already put on our roadmap, only it’ll be under a full catalogue re-imagining (for the better, I promise). Thanks for the feedback!

Heck yes, love this @guillaume . We’re in the early planning stages for tags, providing every level (provider, reseller, tenant) to tag all objects in their respective tiers. I obviously can’t give any indicative times but just know we are totally on board with tags!

We would like to request an enhancement to MultiPortal regarding VM provisioning. Currently, when a VM is created with UEFI boot, the boot disk is automatically created in RAW format. This causes an issue when the storage backend is an LVM LUN, as RAW disks do not support snapshots in this configuration. Requested enhancement: Please add an option to specify the disk format (for example, QCOW2) for the UEFI boot disk during VM creation. Benefits: Enable snapshot support for VMs stored on LVM-backed storage. Provide greater flexibility in storage configuration. Allow administrators to choose the most appropriate disk format based on their storage backend and operational requirements. Current behavior: UEFI boot disk is always created in RAW format. Snapshot creation is not possible when the VM is stored on an LVM LUN. Expected behavior: Allow administrators to select the boot disk format (RAW or QCOW2) when provisioning a UEFI VM. Ensure QCOW2 can be used as the boot disk format to support snapshots where applicable.

Totally agree - this is something I’ll be working on

Thanks @Stell! It’s a great news knowing you’re already planning about, because this request come from customers real need. We will looking forward about this! :-)

Great news, thanks! This feature is fundamental for our customers that already upload and download appliances and VMs on their behalf, without admins intervention. Looking forward to see it on MultiPortal! :-)

Perfect, ideally as a provider having the ability to create a new tenant/reseller/VDC and specify the backing resource pool in PVE would work great as we have existing vms and permissions attached to those pools. We have some use cases where sub pools have unique permissions for a subset of the users which provides some helpful options to for organizing vms similar to how virtualcenter uses vm folders for organization.

During the automated installation for “Auto Generate SSL” Caddy requires TCP 80 to be availble for the Acme Challenge for LetsEncrypt. This poses a security risk to allow either NAT translation or public services to allow TCP 80 to the Mulitportal host. There is functionality with Letsencrypt to leverage API tokens to providers such as Cloudflare which is used in e.g. NGINX to allow the LetsEncrypt acme challange to auth via API Token without the need for openning security senstive ports for a public facing service and allows Multiportal to reside in a DMZ airgapped environment from the internet. For example in a NGINX deployment on Ubuntu sudo apt install python3-certbot-dns-cloudflare sudo mkdir /etc/letsencrypt/secrets/cloudflare.ini # Either API Token (recommended) dns_cloudflare_api_token = <enter api token here> chmod 600 /etc/letsencrypt/secrets/cloudflare.ini certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/secrets/cloudflare.ini -d cloudstack.somedomain.org. The available dns providers are as follows depending on python package are, Cloudflare DNS plugin for Certbot DigitalOcean DNS plugin for Certbot DNSimple DNS plugin for Certbot Gehirn DNS plugin for Certbot Google DNS plugin for Certbot Linode DNS plugin for Certbot OVH DNS plugin for Certbot RFC 2136 DNS plugin for Certbot SakuraCloud DNS plugin for Certbot Infomaniak DNS plugin for Certbot RFC 2136 DNS plugin for Certbot Route53 DNS plugin for Certbot SakuraCloud DNS plugin for Certbot Standalone DNS Authenticator plugin for Certbot If there was an option where during the automated install you could select your DNS provider, the installer install the correct package for Caddy and allow input for the API Token to create the .ini file it would provide a secure mechanism to create signed certificates for Caddy while being airgapped for Acme authentication.