public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Mukesh Choudhary <mukesh.mc.2004@gmail.com>, pve-devel@lists.proxmox.com
Subject: Re: Feature Proposal: Proxmox VE Manager UX Improvements
Date: Mon, 14 Sep 2026 11:44:18 +0200	[thread overview]
Message-ID: <7525e0d2-cace-40f0-b16a-c99bfeef6553@proxmox.com> (raw)
In-Reply-To: <CAK0ghbAzorLUogBKv-koaz1xuzqkcC_WXGP6kdS3avuKBgZZRA@mail.gmail.com>



On 9/14/26 9:56 AM, Mukesh Choudhary wrote:
> Hello Proxmox Development Team,

Hi,

> 
> I would like to propose a set of UX improvements for Proxmox VE Manager
> that I have implemented locally as a feature pack.

Thanks for wanting to contribute!

> 
> The goal of this work is to improve some common day-to-day administration
> workflows without changing the underlying Proxmox architecture. Wherever
> possible, the implementation reuses existing Proxmox APIs, permissions,
> stores, task handling, UI components, and existing command/menu logic.
> Implemented improvements
> 
>     1.
> 
>     *Guest Hostname and OS Information*
>     -
> 
>        Display guest hostname and OS information in the VM/LXC summary.
>        -
> 
>        QEMU information is retrieved through the QEMU Guest Agent.
>        -
> 
>        Graceful handling when guest-agent information is unavailable.


Sounds sensible, if there is enough space. The Summary already takes
a large portion of the page on small screens and we must be
careful not to put too much infos there.

>        2.
> 
>     *Open Console in New Tab*
>     -
> 
>        Option to open VM/LXC consoles in a new browser tab.
>        -
> 
>        Middle-click support where applicable.
>        -
> 
>        Existing Proxmox console URL generation and permission handling are
>        retained.

Depends on where/how this is done, but as concept sounds nice

>        3.
> 
>     *One-Click Copy Information*
>     -
> 
>        Copy IP addresses, hostname, OS information, and connection
>        information directly from the UI.
>        -
> 
>        Uses the browser Clipboard API with a fallback mechanism.


Makes sense IMO

>        4.
> 
>     *Custom Resource Grid Columns*
>     -
> 
>        Improved control over the information displayed in the Resource Grid.
>        -
> 
>        Uses the existing Proxmox grid column/state mechanisms.

What exactly do you mean/imagine here? (The description is a bit vague)

>        5.
> 
>     *Bulk VM/LXC Actions*
>     -
> 
>        Select multiple guests and perform common operations such as:
>        -
> 
>           Start
>           -
> 
>           Shutdown
>           -
> 
>           Reboot
>           -
> 
>           Stop
>           -
> 
>        Existing permission checks and confirmation mechanisms are respected.
>        -
> 
>        Individual operation results are reported back to the user.

We already have a bulk api/gui for
start/shutdown/migrate/suspend extending this makes sense to me

>        6.
> 
>     *Task Duration*
>     -
> 
>        Added duration information to the existing Tasks view.
>        -
> 
>        Reuses the existing Proxmox task infrastructure.

Do you mean as an additional column? Sure why not

>        7.
> 
>     *Resource Usage Warnings*
>     -
> 
>        Visual warnings for high CPU, memory, and disk usage.
>        -
> 
>        Uses existing resource/progress UI components.

We already show gauges/charts in different colors for such things,
or what do you have in mind here?

A longer standing plan from us is to have some kind of
'health' dashboard for each cluster that summarizes various
defects/warnings/etc. but this is just a wish from our side,
and would also need some backend apis/data collection.

>        8.
> 
>     *Improved Tag Filtering*
>     -
> 
>        Better tag-based filtering/search within the resource view.
>        -
> 
>        Existing Proxmox tag rendering and filtering mechanisms are reused.

Depends on how it looks/works, but IMO not a bad idea.
You do know we have a global search that also takes tags into account?

>        9.
> 
>     *Keyboard Command Palette / Quick Actions*
>     -
> 
>        Keyboard-driven access to common operations.
>        -
> 
>        Examples include:
> 
>        start
>        shutdown
>        reboot
>        stop
>        console
>        snapshot
> 
>        -
> 
>        Existing permissions, confirmations, and task handling are reused.

As long as there are confirmations and the user can't accidentally
trigger them sound ok to me.

>        10.
> 
>     *Maintenance Mode*
> 
> 
>     -
> 
>     I investigated adding a node Maintenance Mode UI.
>     -
> 
>     I intentionally did not implement this because I could not find a
>     suitable backend API that would provide correct node-maintenance semantics.
>     I did not want to create a frontend-only or misleading implementation.

Yes i think there is a backend api call still missing for that

> 
> Security and implementation considerations
> 
> The implementation has also gone through a code-level audit covering:
> 
>     -
> 
>     Permission handling
>     -
> 
>     XSS protection
>     -
> 
>     ExtJS component lifecycle
>     -
> 
>     Async callbacks
>     -
> 
>     Clipboard handling
>     -
> 
>     Console URL handling
>     -
> 
>     Bulk operation safety
>     -
> 
>     Command-palette safety
>     -
> 
>     API/HTTP method verification
>     -
> 
>     i18n
>     -
> 
>     Existing Proxmox coding patterns
> 
> Several issues found during the audit were corrected, including an
> incorrect HTTP-method assumption for Guest Agent calls, speculative Guest
> Agent field parsing, duplicated command-palette logic, an i18n issue, and
> an asynchronous UI lifecycle issue.

Nice! (security issues would be good to report to security@proxmox.com
see https://pve.proxmox.com/wiki/Security_Reporting )

> 
> The implementation does not introduce new backend APIs or external
> dependencies.
> Current status
> 
> The current changes affect the following main areas:
> 
>     -
> 
>     www/manager6/Utils.js
>     -
> 
>     www/manager6/button/ConsoleButton.js
>     -
> 
>     www/manager6/qemu/CmdMenu.js
>     -
> 
>     www/manager6/lxc/CmdMenu.js
>     -
> 
>     www/manager6/node/CmdMenu.js
>     -
> 
>     www/manager6/panel/IPView.js
>     -
> 
>     www/manager6/panel/GuestAgentInfo.js
>     -
> 
>     www/manager6/panel/GuestStatusView.js
>     -
> 
>     www/manager6/grid/ResourceGrid.js
>     -
> 
>     www/manager6/data/ResourceStore.js
>     -
> 
>     www/manager6/dc/Tasks.js
>     -
> 
>     www/manager6/form/GlobalSearchField.js
>     -
> 
>     www/manager6/Makefile
> 
> The feature pack is approximately 1,450 lines of additions and 60 deletions
> across the current working tree.
> 
> I currently do not have the complete Proxmox development/build environment
> available, so the final make/lint checks and live browser/PVE testing still
> need to be performed on a proper Proxmox development environment.
> 
> I would therefore appreciate feedback from the Proxmox development team on:
> 
>     1.
> 
>     Which of these improvements would be considered appropriate for upstream
>     inclusion?

AFAICS, most if not all of them sound sensible on first glance. Depends
of course on the actual implementation.

>     2.
> 
>     Which features should be split into separate patches?

Generally each feature/fix should be its own patch. It does not make
sense to send a 'mega' patch with multiple features in one.

>     3.
> 
>     Are there existing Proxmox patterns or APIs that should be used
>     differently?

see my answers inline

>     4.
> 
>     Would the development team be interested in reviewing the implementation?

Of course, see below

>     5.
> 
>     What would be the preferred process for me to submit the patches for
>     review?

please refer to our official developer documentation:
https://pve.proxmox.com/wiki/Developer_Documentation

(please note the CLA requirement on the bottom of the page)

patches are sent to this mailing list (e.g. via `git send-email`)

> 
> I am happy to modify the implementation according to the project's coding
> style and architectural preferences and to split the work into smaller,
> focused patches if appropriate.
> 
> Thank you for your time and for maintaining Proxmox VE as an open-source
> project.
> 
> contact reference
> 
> kodecharya@gmail.com
> 
> mukesh.kode@hotmail.com
> 
> content reference
> 
> KodeCharya/pve-manager: Read-Only mirror of the Proxmox VE Managaer API and
> Web UI repository <https://github.com/KodeCharya/pve-manager>
> 
> 
> Best regards,
> 
> Kodecharaya


If there are any open questions, do not hesitate to ask!

Best regards
Dominik





      reply	other threads:[~2026-09-14  9:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13  4:54 Feature Proposal: Proxmox VE Manager UX Improvements Mukesh Choudhary
2026-09-14  9:44 ` Dominik Csapak [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7525e0d2-cace-40f0-b16a-c99bfeef6553@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=mukesh.mc.2004@gmail.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal