From: Dominik Csapak <d.csapak@proxmox.com>
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?
Date: Mon, 13 Jul 2026 15:01:35 +0200 [thread overview]
Message-ID: <eec17f6f-3521-4368-9457-3ce89f6b7c3d@proxmox.com> (raw)
In-Reply-To: <CH3PR11MB849513C3D52AC9211EA54B828AFA2@CH3PR11MB8495.namprd11.prod.outlook.com>
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
prev parent reply other threads:[~2026-07-13 13:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eec17f6f-3521-4368-9457-3ce89f6b7c3d@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=Chiranth.JS@datacore.com \
--cc=Vikash.Ray@datacore.com \
--cc=prajwal.shetty@datacore.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.