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 DBD321FF0E4 for ; Tue, 11 Aug 2026 11:42:47 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id DA61E2159C; Tue, 11 Aug 2026 11:42:40 +0200 (CEST) Message-ID: <602291cb-edfa-4dc3-8e6c-33224de64318@proxmox.com> Date: Tue, 11 Aug 2026 11:42:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: Supported way to extend the PVE web UI for a third-party package? To: Chiranth J S , "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: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1786441342619 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.455 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_ASCII_DIVIDERS 0.8 Email that uses ascii formatting dividers and possible spam tricks KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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: RZVQKO5ENLAJ6SIYYR6MHSLWCMRIPE3Z X-Message-ID-Hash: RZVQKO5ENLAJ6SIYYR6MHSLWCMRIPE3Z 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 CC: Vikash Ray , Prajwal Shetty , Rajkumar Rajamanickam , Alex Best X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi, On 7/17/26 4:58 PM, Chiranth J S wrote: > Hi @Dominik Csapak > Thank you for pointing us to the ongoing work on custom storage plugin > UI schemas. We've reviewed the discussion, and while it addresses part > of the extensibility story, it doesn't fully cover our use case. I > wanted to clarify the gap and explain what we're looking for. > Our primary requirement is the ability for plugins to register custom > operational tabs within: > > * A VM's detail view (alongside existing tabs such as Hardware, > Monitor, etc.) IMO this should maybe not be a part of a storage plugin, because the storage shouldn't interact with VMs in a direct way (see further below) > * A storage's detail view Could maybe be done (no current plans though), but we'd have to be careful about security etc. so that such a plugin does not have the capability to inject code/modify our stock UI. The reason for this is simply that it makes supporting customers harder when there are a multitude of plugins that modify the GUI and even maybe interfering with each other. (Writing a plugin system for JS/HTML that is properly encapsulated is not easy) I see that there are already multiple projects/plugins/etc. that modify the gui (mostly via file modification and/or diverts) and add functionality, so I personally would favor a proper way to do this. (however we would implement that on the technical side) I'm not sure how my colleagues see that though, so this requires a bit of (internal) discussion. > > These tabs would allow a storage plugin to expose backend operations > such as rollback management, snapshot, and performance directly within > the Proxmox UI, without requiring operators to switch to external > management tools. > *Why this matters* > For a SANsymphony setup, a VM rollback using CDP currently involves > several manual steps across multiple interfaces: > > 1. Select the desired recovery point in the DataCore management console. > 2. Initiate the rollback and present the recovered storage to the > appropriate Proxmox nodes. > 3. > Identify the affected virtual disks. > 4. > For RDM disks: manually create a new VM on top of the recovered disk > 5. > For LVM-backed disks: Create an LVM volume on top of the recovered > storage and then create a VM using the appropriate logical volume. > > If plugins could expose custom operational tabs within the Proxmox UI, > much of this workflow could be streamlined or automated. An > administrator could initiate the rollback directly from the VM's detail > page and continue the recovery process without leaving Proxmox, > resulting in a significantly smoother operational experience for a > common disaster recovery workflow. > *Existing precedent* > This model is supported in VMware vSphere, where third-party storage > vendors can integrate directly into the VM and datastore configuration > views through custom tabs. We've attached a few screenshots of the > vCenter integration to illustrate the type of user experience we're > aiming for. > ** > * > * (Side question: can you share a bit how this kind of interface works on the vmware side regarding GUI plugins?) Ignoring for now the details how the storage/etc. and vmware works, I have a bit of a concern with this: In PVE a snapshot is always considering the whole VM never only a single disk. So a PVE snapshot includes the config and all disks on all storages, and a rollback touches all this. If a storage exposes an easy way to roll back a single disk, this now is not in sync anymore with PVE's view of its snapshots. There is a use case for rolling back single disks I think, but allowing this from the PVE side would be a rather big change in semantics for our snapshots (and the interactions would have to be considered carefully) > *Our question* > Would the Proxmox team be open to considering UI extensibility in this > direction? We're not asking for an immediate implementation—rather, we'd > like to understand whether this aligns with the long-term vision for the > UI architecture, or whether such extensibility is intentionally outside > the project's scope. > If this is something that aligns with the project's roadmap, we'd also > be happy to explore contributing toward such an extensibility framework. > We understand that this is ultimately subject to the project's > priorities and design direction, but we'd be glad to collaborate if such > contributions would be useful. > Thank you for your time and for considering this request. > Best regards, > Chiranth JS As said above, I'd personally favor a proper solution for vendor and community extensions/plugins, but this is not an easy thing to do right. I'll see that we discuss this internally, but even if we would implement such a thing, I guess it'll not be available in the near future. Hope this helps as a first answer Best regards Dominik > > ------------------------------------------------------------------------ > *From:* Chiranth J S > *Sent:* Friday, July 17, 2026 13:31 > *To:* Dominik Csapak ; pve-devel@lists.proxmox.com > > *Cc:* Vikash Ray ; Prajwal Shetty > ; Rajkumar Rajamanickam > ; Alex Best > *Subject:* Re: Supported way to extend the PVE web UI for a third-party > package? > > Hello, > > Thanks for the clear answer — that settles the "should we patch stock > files" question for us. > > Quick follow-up on something that came up while reviewing our storage > architecture. > > Today, PVE's native LVM storage type can sit on top of an existing > shared volume group — including one backed by a default iSCSI plugin — > and PVE handles dynamic LV creation automatically. > > Is there a plan to generalize that "LVM-on-top" mechanism so any SCSI/ > block-based custom storage plugin can get the same dynamic per-volume > provisioning, without each plugin having to implement its own volume- > creation logic? > > If this is already possible today and we've just missed the hook, a > pointer would be really helpful. If not, we'd be happy to write it up as > a feature request. > > Thanks again for your time. > > Best regards, > Chiranth JS > > ------------------------------------------------------------------------ > *From:* Dominik Csapak > *Sent:* Monday, July 13, 2026 18:31 > *To:* Chiranth J S ; pve- > devel@lists.proxmox.com > *Cc:* Vikash Ray ; Prajwal Shetty > > *Subject:* Re: Supported way to extend the PVE web UI for a third-party > package? > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > On 7/13/26 1:59 PM, Chiranth J S wrote: > > Hello, > > Hi, > > > > > I work at DataCore SANsymphony team. We ship a SANsymphony storage > backend for PVE on the supported PVE::Storage::Plugin contract, > presenting vDisks over iSCSI. That side has worked well and is in > production with customers. > > Great to hear! > > > > > We also have a prototype that adds a native-feeling UI on top of it > (a tab with vDisk aliases, snapshot/rollback, resize and performance). > Since we couldn't find an official UI-extension hook, it currently works > by patching two pve-manager files at install time — adding a