From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Andrei Perepiolkin <andrei.perepiolkin@open-e.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] storage plugin volume sync during live migration
Date: Wed, 18 Feb 2026 08:30:47 +0100 [thread overview]
Message-ID: <1771399591.15k1mhcwf2.astroid@yuna.none> (raw)
In-Reply-To: <f843995b-8f7b-493c-9183-fc5497e9610a@open-e.com>
On February 17, 2026 1:06 pm, Andrei Perepiolkin wrote:
> Hi,
>
> I have a question regarding Proxmox storage plugin
> activate_volume/deactivate_volume concurrency for shared volumes.
>
> During live migration volume can be simultaneously attached to multiple
> nodes at same time.
> If vm migrates from node1 to node2, activate volume on node2 will
> be called before deactivate is done on node1.
>
> This raises question regarding concurrency, a specially for sync-like
> operations.
>
> Does Proxmox have any mean to guaranty that no I/O will be performed on
> node2 until deactivation on node1 is completed?
It is ensured that the guest doesn't do any I/O, because the sequence is
like this:
1. VM is running on source node
2. VM is started in suspended state on target node (this means no guest
execution)
3. state (RAM, ..) is transferred until it converges
4. VM on source node is automatically paused once state is synced up
5. config file is moved to target node to hand over ownership
6. VM is resumed on target node
7. VM is stopped/killed on source node
the VM is "logically" down (no guest execution on either node) from 4 to
6. up to 4, only the VM on the source node is actually executing the
guest. after 6, only the VM on the target node is actually executing the
guest.
it becomes a bit more involved if you mix in local disks (in addition or
instead of shared disks), but the principle remains the same.
> Can I/O operation take place on node2 before activation on node2 is
> completed?
only if your storage does that on its own. if it does so in a
problematic fashion, it's not really a useful shared storage ;)
Fabian
prev parent reply other threads:[~2026-02-18 7:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 12:06 Andrei Perepiolkin
2026-02-18 7:30 ` Fabian Grünbichler [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=1771399591.15k1mhcwf2.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=andrei.perepiolkin@open-e.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.