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

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

[Chiranth J S]

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

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

[Dominik Csapak]

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

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

[Chiranth J S]

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/

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

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

[Dominik Csapak]

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
> 

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

[Dominik Csapak]

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
>