From: Fabian Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH container] fix #3030: activate volumes at the right time for restart migration
Date: Thu, 29 Oct 2020 09:26:00 +0100 [thread overview]
Message-ID: <983c73e4-47a5-0599-7a88-3f292eb13d40@proxmox.com> (raw)
In-Reply-To: <1603890752.4d64scs2iw.astroid@nora.none>
Am 28.10.20 um 14:15 schrieb Fabian Grünbichler:
> On October 15, 2020 12:24 pm, Fabian Ebner wrote:
>> The lxc-pve-poststop-hook deactivates volumes when a container is stopped.
>> To make sure that volumes are active when using the restart mode,
>> move activate_volumes to after the conditional vm_stop. The lxc-stop command
>> used in vm_stop waits for the hook script to complete, so there is no race.
>>
>> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
>> ---
>>
>> For VMs we don't have restart migration, so no similar bug there.
>>
>> An alternative would be to communicate to the hook script to
>> not deactivate the volumes. That would mean writing the lock=migrate
>> to the config earlier (currently it's being set in phase1) and
>> then checking for the lock in the hookscript.
>
> isn't this still wrong, as it only activates the volumes directly
> referenced by the config, but we storage migrate unused (referenced and
> unreferenced) and snapshot volumes as well? wouldn't it make more sense
> that storage_migrate ensures the passed-in volid is activated before
> accessing it? and then before switching the container over, we ensure
> all volids we passed to storage_migrate get deactivated.. the others
> were already deactivated by the container shutting down anyway.
>
You're right, and with volumes not referenced in the config, the QEMU
code is also affected by the issue.
Should we still keep the current activate_volumes in prepare? I imagine
one reason it's there, is that we would die early. If we move activation
to within storage_migrate we'd lose that. But I can check that the
volumes are not required to be active somewhere else during migration
and remove the call in prepare if that's preferred.
Alternatively, we could move the activate_volumes call to before the
loop where we repeatedly call storage_migrate.
In the long run, we might want to rework storage_migrate a bit, having
it take a list of volumes instead, and separating the checks+activation
and the transfer itself. With the goal of being able to die early for
problems like "target storage doesn't support format" or "activation
failed".
>>
>> src/PVE/LXC/Migrate.pm | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/PVE/LXC/Migrate.pm b/src/PVE/LXC/Migrate.pm
>> index 90d74b4..5ef16d2 100644
>> --- a/src/PVE/LXC/Migrate.pm
>> +++ b/src/PVE/LXC/Migrate.pm
>> @@ -90,8 +90,6 @@ sub prepare {
>>
>> });
>>
>> - PVE::Storage::activate_volumes($self->{storecfg}, $need_activate);
>> -
>> # todo: test if VM uses local resources
>>
>> # test ssh connection
>> @@ -110,6 +108,8 @@ sub prepare {
>> $running = 0;
>> }
>>
>> + PVE::Storage::activate_volumes($self->{storecfg}, $need_activate);
>> +
>> return $running;
>> }
>>
>> --
>> 2.20.1
>>
>>
>>
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>
>>
>>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
prev parent reply other threads:[~2020-10-29 8:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 10:24 Fabian Ebner
2020-10-28 13:15 ` Fabian Grünbichler
2020-10-29 8:26 ` Fabian Ebner [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=983c73e4-47a5-0599-7a88-3f292eb13d40@proxmox.com \
--to=f.ebner@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