Feature Requests

Currently, the VM creation page in Multiportal does not allow configuring the number of vCPUs or enabling NUMA. As a result, it is not possible to use CPU hotplug on newly created VMs and the configuration has to be adjusted afterwards. We would like these options to be available directly in the creation wizard. Please consider adding the following fields to the VM creation page: vCPU configuration vCPU field editable by the user in the VM creation page. NUMA A checkbox to enable NUMA on the VM. CPU hotplug Once NUMA is enabled, allow the VM to be created with CPU hotplug active, so that vCPUs can be added at runtime without a reboot. Ideally, a tooltip or note explaining that NUMA is required for CPU hotplug and that the guest OS must support it. For VMs that use the vCPU field, we would suggest that CPU consumption be calculated based on the vCPUs, rather than on the maximum number of CPUs (sockets * cpus).

Hi, Is there a feature like Migration or cloning between tenants on the roadmap? At the moment we use vApp Templates with vCloud Director which have several configured machines in one template. We would like for example a Tenant or any other repository that holds all these configured setups and then be able to clone them to whichever other tenant needs a specific setup. Thanks!

Hey @peconi we can arrange a roadmap/what’s new session for the upcoming 1.3.0 release if you’d like? While it seems MP hasn’t had any love I can assure you this release is absolutely monstrous :D We know about the API issues, we’re pushing hard to get this sorted

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.