* plugin reentrant?
@ 2026-06-17 19:45 Anthony Galica
2026-06-18 6:42 ` Fabian Grünbichler
0 siblings, 1 reply; 3+ messages in thread
From: Anthony Galica @ 2026-06-17 19:45 UTC (permalink / raw)
To: pve-devel@lists.proxmox.com
Hi Everyone,
Is a proxmox plugin reentrant in that will it simultaneously send two or more requests to the same instance of the running script?
Does the answer differ for the same storage pool vs. different storage pools?
Thank you!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: plugin reentrant?
2026-06-17 19:45 plugin reentrant? Anthony Galica
@ 2026-06-18 6:42 ` Fabian Grünbichler
2026-06-19 16:43 ` Anthony Galica
0 siblings, 1 reply; 3+ messages in thread
From: Fabian Grünbichler @ 2026-06-18 6:42 UTC (permalink / raw)
To: Anthony Galica, pve-devel@lists.proxmox.com
On June 17, 2026 9:45 pm, Anthony Galica wrote:
> Hi Everyone,
>
> Is a proxmox plugin reentrant in that will it simultaneously send two or more requests to the same instance of the running script?
There can be more than one *process* calling into storage plugin perl
code at the same time - API requests are processed concurrently,
including long-running tasks executed in their own worker process, and
CLI tools can also call into plugin code via PVE::Storage.
For some code paths, there will be a mutual exclusion mechanism in
effect via pmxcfs cluster-wide locking for shared storages, and
node-local locking for local storages.
Those mostly cover code paths related to allocating or freeing volumes.
> Does the answer differ for the same storage pool vs. different storage pools?
Currently, the locking done by PVE is per storage plugin instance (which
is normally one pool/export/directory/.. ). We have discussed allowing
storage plugins to mark themselves as not requiring such a coarse lock,
in which case we would instead lock the (storage plugin instance, VMID)
tuple - but that is not yet implemented.
If you have different locking requirements, you can of course implement
your own locking inside your plugin on top of what PVE does - but please
be careful to not cause accidental deadlocks.
Hope this helps - please reach out if you have more questions!
Fabian
P.s. if you are developing your own custom storage plugin, we'd be
interested to know about it!
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: plugin reentrant?
2026-06-18 6:42 ` Fabian Grünbichler
@ 2026-06-19 16:43 ` Anthony Galica
0 siblings, 0 replies; 3+ messages in thread
From: Anthony Galica @ 2026-06-19 16:43 UTC (permalink / raw)
To: Fabian Grünbichler, pve-devel@lists.proxmox.com
Thanks, Fabian.
This is more or less what I expected (cross process execution concurrency, but not in-process concurrency), but obviously there are different considerations so I wanted to make sure.
As to the PS: We are developing a custom plugin, but at the moment I can't share much about it!
Thanks again,
Anthony
-----Original Message-----
From: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Sent: Wednesday, June 17, 2026 11:43 PM
To: Anthony Galica <anthony.galica@hitachivantara.com>; pve-devel@lists.proxmox.com
Subject: Re: plugin reentrant?
***** EXTERNAL EMAIL *****
On June 17, 2026 9:45 pm, Anthony Galica wrote:
> Hi Everyone,
>
> Is a proxmox plugin reentrant in that will it simultaneously send two or more requests to the same instance of the running script?
There can be more than one *process* calling into storage plugin perl code at the same time - API requests are processed concurrently, including long-running tasks executed in their own worker process, and CLI tools can also call into plugin code via PVE::Storage.
For some code paths, there will be a mutual exclusion mechanism in effect via pmxcfs cluster-wide locking for shared storages, and node-local locking for local storages.
Those mostly cover code paths related to allocating or freeing volumes.
> Does the answer differ for the same storage pool vs. different storage pools?
Currently, the locking done by PVE is per storage plugin instance (which is normally one pool/export/directory/.. ). We have discussed allowing storage plugins to mark themselves as not requiring such a coarse lock, in which case we would instead lock the (storage plugin instance, VMID) tuple - but that is not yet implemented.
If you have different locking requirements, you can of course implement your own locking inside your plugin on top of what PVE does - but please be careful to not cause accidental deadlocks.
Hope this helps - please reach out if you have more questions!
Fabian
P.s. if you are developing your own custom storage plugin, we'd be interested to know about it!
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-06-19 16:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-17 19:45 plugin reentrant? Anthony Galica
2026-06-18 6:42 ` Fabian Grünbichler
2026-06-19 16:43 ` Anthony Galica
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox