public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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!


      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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal