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!

@ranjina.vazhayil , thanks for the confirmation, I’ll provide this to our team to see if we can replicate it.

Hi Currently, the manual installation process requires direct internet access, which prevents deployments in environments where outbound connections must go through a proxy. This is a significant limitation for organizations with strict security policies. We would also like the license validation/check to be able to use the configured proxy instead of requiring direct internet access. Providing full proxy support for the installation process and all external communications, including license verification, would greatly simplify deployments in secured and restricted environments. sincelery

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.

Thanks :) I really wanted it to match our new site as well as WHMCS so clients get a fully “brand” experience…

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! :-)

Hey @danielbfusionred we’re actually adding something like this for storage changes in the next release. Feedback noted: we’ll look at adding pending reboots for other changes.

Hey MikeD, thanks for the post! We’re aware of this bug and we’re already investigating it.

Hey @southwalesowl, Adding the 127.0.0.1 multiportal.calligo.cloud hosts entry just allows MultiPortal and the console server to talk to each other locally, however, the error you now have ECONNREFUSED 127.0.0.1:443 means the console server cannot reach MultiPortal locally on port 443. That loopback shortcut only works when MultiPortal is handling its own traffic directly on the server. Can you please confirm: MultiPortal was installed using the automated script? Is an SSL configured on the box, or are you using a Load Balancer for MultiPortal? Confirm the system is reporting on port 443 sudo ss -ltnp | grep ':443' You should see something like ⎿ LISTEN 0 4096 *:443 *:* users:(("caddy",pid=4140634,fd=7)) Can you also comment out that hosts entry you added to your MultiPortal server, restart the console server, and try connecting again? Let me know if the old error comes back after you regenerated the new API key. Matt

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! :-)

I performed an additional test by running: php yii vm-post-task/process The command returns: Unable to get status for Proxmox task UPID:iaas-pve-s1-002:001E1CD9:01149D63:6A2D92BF:qmclone:103:multiportal@pve!ertyfghj: Proxmox task UPID:iaas-pve-s1-002:001E1CD9:01149D63:6A2D92BF:qmclone:103:multiportal@pve!ertyfghj: is still running, skipping... However, the clone operation has already completed successfully in Proxmox and the VM exists and is fully created. It appears that MultiPortal is unable to correctly determine the final status of the Proxmox clone task and continues to consider the UPID as running. This may also explain why the post-clone task never completes. Regarding the network issue, I can confirm that the network adapter is requested during deployment from the template, but it is never added to the VM. The network interface is missing not only in MultiPortal, but also in the VM configuration directly in Proxmox. As a result, the deployed VM is created without any network device attached. Could there be an issue with task status polling or UPID tracking in MultiPortal when used with Proxmox VE 9.2.3? One additional point that may be relevant: this is a brand new MultiPortal installation deployed in an offline environment behind a proxy. The documentation is not very explicit regarding offline deployments and proxy requirements, so I am not completely sure whether my installation is fully operational or if there are additional configuration steps required for this type of environment. Could you advise on how I can verify that the installation is healthy and fully functional? Are there any specific services, connectivity checks, background workers, queue processors, or diagnostic commands that should be validated after an offline installation behind a proxy? I would like to rule out any installation or connectivity issues before investigating the cloning and post-clone task problems further.

@AlessandroRamon Love the idea for an Italian translation! I’ll add it to the backlog. Here’s a tiny spoiler: tier-specific documentation (Provider, Reseller, Tenant).

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.

Hey @csmo I’ve just sent you a message asking for your logs, there is some information that I need to check. The most common issue that comes up, specifically with local-lvm, is if you’re running more than one Proxmox node. Are you able to confirm if you have more than one node, that shares the same name? Matt

You’re not going crazy, we haven’t announced PVE 9.2 support yet. We’re working on it I swear!

@heky said: But now in 1.1.3 there is another error Error: Validation failed: {“ciuser”:[“Username is required when any cloud-init field is set.”]} So probably you need to address this. Creation VM from template is not possible.[image: 1779944432275-screenshot-2026-05-28-at-07.00.08-resized.png] @heky Can you please see my message I incorrectly directed to Twallace-armor.

Yep great feedback. I’ll get this logged and into our backlog with a priority. Thanks @pean !

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.