* Supported way to extend the PVE web UI for a third-party package?
@ 2026-07-13 10:26 Chiranth J S
2026-07-13 13:01 ` Dominik Csapak
0 siblings, 1 reply; 2+ messages in thread
From: Chiranth J S @ 2026-07-13 10:26 UTC (permalink / raw)
To: pve-devel@lists.proxmox.com; +Cc: Vikash Ray, Prajwal Shetty
Hello,
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.
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Supported way to extend the PVE web UI for a third-party package?
2026-07-13 10:26 Supported way to extend the PVE web UI for a third-party package? Chiranth J S
@ 2026-07-13 13:01 ` Dominik Csapak
0 siblings, 0 replies; 2+ messages in thread
From: Dominik Csapak @ 2026-07-13 13:01 UTC (permalink / raw)
To: Chiranth J S, pve-devel@lists.proxmox.com; +Cc: Vikash Ray, Prajwal Shetty
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/
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
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-07-13 13:02 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-13 10:26 Supported way to extend the PVE web UI for a third-party package? Chiranth J S
2026-07-13 13:01 ` Dominik Csapak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox