Feature Proposal: Proxmox VE Manager UX Improvements

Feature Proposal: Proxmox VE Manager UX Improvements

[Mukesh Choudhary]

Hello Proxmox Development Team,

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

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.
      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.
      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.
      4.

   *Custom Resource Grid Columns*
   -

      Improved control over the information displayed in the Resource Grid.
      -

      Uses the existing Proxmox grid column/state mechanisms.
      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.
      6.

   *Task Duration*
   -

      Added duration information to the existing Tasks view.
      -

      Reuses the existing Proxmox task infrastructure.
      7.

   *Resource Usage Warnings*
   -

      Visual warnings for high CPU, memory, and disk usage.
      -

      Uses existing resource/progress UI components.
      8.

   *Improved Tag Filtering*
   -

      Better tag-based filtering/search within the resource view.
      -

      Existing Proxmox tag rendering and filtering mechanisms are reused.
      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.
      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.

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.

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?
   2.

   Which features should be split into separate patches?
   3.

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

   Would the development team be interested in reviewing the implementation?
   5.

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

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

Re: Feature Proposal: Proxmox VE Manager UX Improvements

[Dominik Csapak]

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