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

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

Hi,

appreciate the answer and thank you for you patience.


On 7/17/26 10:01 AM, Chiranth J S wrote:
> 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?

This is not planned, but I can see this being valuable for storage
plugins, so I'll relay that and we'll discuss this internally.

 From the technical POV this is probably not hard to do, we just
have to expose a mechanism for plugins to mark themselves as being
able to used in such a way and they have to provide a 'path' that
can be used for LVM.

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

I'll answer your other follow up question separately.

Best regards
Dominik

> 
> ------------------------------------------------------------------------
> *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
>