From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 03AF31FF09B for ; Mon, 14 Sep 2026 11:44:28 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 7562D215A9; Mon, 14 Sep 2026 11:44:25 +0200 (CEST) Message-ID: <7525e0d2-cace-40f0-b16a-c99bfeef6553@proxmox.com> Date: Mon, 14 Sep 2026 11:44:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: Feature Proposal: Proxmox VE Manager UX Improvements To: Mukesh Choudhary , pve-devel@lists.proxmox.com References: Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1789379045881 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.469 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: LBCYUOEALYMKHEFJAB2K25WIYNDOCH6N X-Message-ID-Hash: LBCYUOEALYMKHEFJAB2K25WIYNDOCH6N X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 > > > Best regards, > > Kodecharaya If there are any open questions, do not hesitate to ask! Best regards Dominik