Re: Supported way to extend the PVE web UI for a third-party package?

[Dominik Csapak <d.csapak@proxmox.com>]

Hi,


On 7/17/26 4:58 PM, Chiranth J S wrote:
> Hi @Dominik Csapak <mailto:d.csapak@proxmox.com>
> 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 <Chiranth.JS@datacore.com>
> *Sent:* Friday, July 17, 2026 13:31
> *To:* Dominik Csapak <d.csapak@proxmox.com>; pve-devel@lists.proxmox.com 
> <pve-devel@lists.proxmox.com>
> *Cc:* Vikash Ray <Vikash.Ray@datacore.com>; Prajwal Shetty 
> <prajwal.shetty@datacore.com>; Rajkumar Rajamanickam 
> <Rajkumar.Rajamanickam@datacore.com>; Alex Best <Alex.Best@datacore.com>
> *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 <d.csapak@proxmox.com>
> *Sent:* Monday, July 13, 2026 18:31
> *To:* Chiranth J S <Chiranth.JS@datacore.com>; pve- 
> devel@lists.proxmox.com <pve-devel@lists.proxmox.com>
> *Cc:* Vikash Ray <Vikash.Ray@datacore.com>; Prajwal Shetty 
> <prajwal.shetty@datacore.com>
> *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 <script> 
> tag to index.html.tpl and a register_method for a /nodes/<node>/ 
> datacore/... route in PVE/API2/Nodes.pm — with a dpkg trigger to re- 
> apply after upgrades.
>  >
>  > We understand the long-standing guidance that features should be 
> added "directly, no plugin," and we're weighing whether to productize 
> this. Before we decide, two questions:
>  >
>  >
>  >    1.
>  > Is there any supported or planned mechanism to extend the PVE web UI 
> (add a view/tab) or register a nodes/<node>/... API2 route from a third- 
> party package — anything analogous to the storage plugin contract, but 
> for the frontend?
>  >    2.
>  > If not, is in-place patching of index.html.tpl / Nodes.pm considered 
> an acceptable approach (several community projects do this), or does it 
> put a node in an unsupported state from your perspective? Is there a 
> pattern you'd recommend instead?
>  >
>  >
>  > A clear "there's no supported hook, don't patch core files" is just 
> as useful to us as a yes.
>  > Thanks for your time, and for the storage plugin API.
>  >
>  > Best regards,
>  > Chiranth JS
>  >
> Currently there is no hook to extend the GUI or add any API calls.
> 
> There is ongoing work to expose a schema for custom storage plugins so
> they can be added/edited/etc. via the GUI:
> 
> https://lore.proxmox.com/pve-devel/20260623143402.772452-1- 
> m.carrara@proxmox.com/ <https://lore.proxmox.com/pve- 
> devel/20260623143402.772452-1-m.carrara@proxmox.com/>
> 
> However, this is still very much in progress. Feedback is welcome
> though, the sooner we can gauge external needs and requirements,
> the better.
> 
> I'm not sure what kind of integration you've built or are planning,
> but as far as I know, there is no plan to allow external vendors
> to add generic UI functionality or API calls.
> 
> Modifying the files we ship is always problematic: they will be
> overwritten by a package update and depending on how the patching is
> done, it might break our UI and/or can cause support issues on our side.
> 
> So we'd strongly prefer that vendors do not modify the stock PVE files.
> 
> That said, if you've identified a place where PVE could benefit from
> such a plugin/extension, please discuss (as concretely as possible) such
> requirements here on the mailing list or via our bugtracker:
> https://bugzilla.proxmox.com <https://bugzilla.proxmox.com>
> 
> We can't promise to implement anything specific, but understanding what
> vendors might need or want can help us (and you) find a solution that
> benefits both.
> 
> Hope this answers your questions, don't hesitate to follow up or open
> bug reports and feature requests.
> 
> Best regards
> Dominik
>