From: Anthony Galica <anthony.galica@hitachivantara.com>
To: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
"pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: RE: plugin reentrant?
Date: Fri, 19 Jun 2026 16:43:52 +0000 [thread overview]
Message-ID: <IA1PR08MB862129BE89AD71B12742D928F8E22@IA1PR08MB8621.namprd08.prod.outlook.com> (raw)
In-Reply-To: <1781764622.asu64jnlli.astroid@yuna.none>
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!
prev parent reply other threads:[~2026-06-19 16:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 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=IA1PR08MB862129BE89AD71B12742D928F8E22@IA1PR08MB8621.namprd08.prod.outlook.com \
--to=anthony.galica@hitachivantara.com \
--cc=f.gruenbichler@proxmox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox