From: Fabian Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server] migrate: keep VM paused after migration if it was before
Date: Thu, 21 Apr 2022 09:44:42 +0200 [thread overview]
Message-ID: <29ca4b42-5260-ecb2-0a5d-858dbf6a4b93@proxmox.com> (raw)
In-Reply-To: <1650457969.m5c6lqzh1t.astroid@nora.none>
Am 20.04.22 um 14:43 schrieb Fabian Grünbichler:
> On March 18, 2022 8:51 am, Fabian Ebner wrote:
>> Also cannot issue a guest agent command in that case.
>>
>> Reported in the community forum:
>> https://forum.proxmox.com/threads/106618
>>
>> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
>> ---
>>
>> Best viewed with -w.
>>
>> PVE/QemuMigrate.pm | 54 ++++++++++++++++++++++++++--------------------
>> 1 file changed, 31 insertions(+), 23 deletions(-)
>
> patch looks good to me - it might make sense to restructure the
> conditionals a bit to log that resuming/fstrim was skipped though to
> reduce confusion (user that paused VM and user doing the migration might
> not be the same entity after all)?
>
> one other thing I noticed (pre-existing, but the changes here made me
> look and my search came up short), inside phase2:
>
> - start block job(s) without autocompletion and wait for them to
> converge
> - start RAM/state migration without autocompletion and wait for it to
> converge
> X both source and target VMs are paused now with "identical" state,
> irrespective of the source being paused or not initially
> - cancel block job(s) (to close NBD writer(s) so that switchover can
> proceed in phase3_cleanup)
>
> if something happens after X in phase2, we enter phase2_cleanup, and
> attempt to cancel the migration
If migrate_cancel actually cancels the migration, the VM will be running
on the source node again :)
If migrate_cancel fails, resume might also fail?
There is an edge case however:
If migration actually finished, but we aborted because of e.g. too many
query-migrate failures, then migrate_cancel will succeed (because there
is no active migration) and the VM will be in post-migrate state on the
source node. Here, resume would help.
> , remove the lock, cancel the block jobs
> again, clean up bitmaps, stop the target VM, clean up remote disks, tear
> down the tunnel, and effectively exit the migration at that point BUT -
> we don't handle the paused state? is there a resume source (with this
> patch, guarded by source was not paused) missing or am I missing
> something?
>
next prev parent reply other threads:[~2022-04-21 7:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-18 7:51 Fabian Ebner
2022-04-20 12:43 ` Fabian Grünbichler
2022-04-21 7:20 ` Fabian Ebner
2022-04-21 7:35 ` Fabian Grünbichler
2022-04-21 7:44 ` Fabian Ebner [this message]
2022-04-21 9:15 ` Fabian Grünbichler
2022-04-25 10:48 ` Fabian Ebner
2022-04-21 7:02 ` [pve-devel] applied: " Thomas Lamprecht
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=29ca4b42-5260-ecb2-0a5d-858dbf6a4b93@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.