From: Fabian Ebner <f.ebner@proxmox.com>
To: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH v3 guest-common 1/1] guest helpers: add run_with_replication_guard
Date: Tue, 22 Feb 2022 14:44:29 +0100 [thread overview]
Message-ID: <95357aad-53db-8be7-9699-8cd310ba7633@proxmox.com> (raw)
In-Reply-To: <1645524681.xz819fggl9.astroid@nora.none>
Am 22.02.22 um 11:27 schrieb Fabian Grünbichler:
> On February 22, 2022 10:41 am, Fabian Ebner wrote:
>> Am 21.02.22 um 12:58 schrieb Fabian Ebner:
>>> @@ -82,6 +83,18 @@ sub guest_migration_lock {
>>> return $res;
>>> }
>>>
>>> +sub run_with_replication_guard {
>>> + my ($vmid, $timeout, $log, $func, @param) = @_;
>>> +
>>> + my $repl_conf = PVE::ReplicationConfig->new();
>>> + if ($repl_conf->check_for_existing_jobs($vmid, 1)) {
>>> + $log->("checking/waiting for active replication..") if $log;
>>> + guest_migration_lock($vmid, $timeout, $func, @param);
>>
>> I wonder if we should unconditionally take the lock? If not, we can race
>> with a newly created replication job:
>> 1. snapshot deletion starts
>> 2. replication job is created
>> 3. replication job starts
>> 4. snapshot deletion runs into 'dataset is busy' error, because snapshot
>> is used by replication
>
> that could also be solved by lock_config on the guest config when
> creating/modifying a replication job, but unconditionally trying to
> obtain the lock is also fine by me.
>
Should be enough to do upon creation and would also fix a race between
creating a replication job and adding a non-replicatable disk.
next prev parent reply other threads:[~2022-02-22 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-21 11:58 [pve-devel] [PATCH-SERIES guest-common/container/qemu-server] fix #3424: wait for active replication when deleting a snapshot Fabian Ebner
2022-02-21 11:58 ` [pve-devel] [PATCH v3 guest-common 1/1] guest helpers: add run_with_replication_guard Fabian Ebner
2022-02-22 9:41 ` Fabian Ebner
2022-02-22 10:27 ` Fabian Grünbichler
2022-02-22 13:44 ` Fabian Ebner [this message]
2022-02-21 11:58 ` [pve-devel] [PATCH v3 container 1/2] partially fix #3424: vzdump: cleanup: wait for active replication Fabian Ebner
2022-02-21 11:58 ` [pve-devel] [PATCH v3 container 2/2] fix #3424: api: snapshot delete: " Fabian Ebner
2022-02-21 11:58 ` [pve-devel] [PATCH v3 qemu-server 1/1] " Fabian Ebner
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=95357aad-53db-8be7-9699-8cd310ba7633@proxmox.com \
--to=f.ebner@proxmox.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 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.