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
prev parent 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