Re: [libvirt PATCH 06/80] qemu: Keep domain running on dst on failed post-copy migration
On Wed, May 11, 2022 at 11:39:29 +0100, Daniel P. Berrangé wrote:
On Wed, May 11, 2022 at 10:48:10AM +0200, Peter Krempa wrote:
> On Tue, May 10, 2022 at 17:20:27 +0200, Jiri Denemark wrote:
> > There's no need to artificially pause a domain when post-copy fails. The
> > virtual CPUs may continue running, only the guest tasks that decide to
> > read a page which has not been migrated yet will get blocked.
>
> IMO not pausing the VM is a policy decision (same way as pausing it was
> though) and should be user-configurable at migration start.
>
> I can see that users might want to prevent a half-broken VM from
> executing until it gets attention needed to fix it, even when it's safe
> from a "theoretical" standpoint.
It isn't even safe from a theoretical standpoint though.
Consider 2 processes in a guest that are communicating with each
other. 1 gets blocked on a page rea due to broken post copy, but
we leave the guest running. The other process sees no progress
from the blocked process and/or hits time timeout and throws an
error. As a result the guest application workload ends up
completely dead, even if we later recover the the postcopy
migration.
IMO you have to deal with this scenario in a reduced scope anyways when
opting into using post-copy.
Each page transfer is vastly slower than the comparable access into
memory, so if the 'timeout' portion is implied to be on the same order
of magnitde of memory access latency then your software is going to have
a very bad time when being migrated in post-copy mode. If the link gets
congested ... then it's even worse.
Obviously when the migration link breaks and you are getting unbounded
wait for a page access it's worse even for other types of APPs.
Anyways, does qemu support pausing the destination if the connection
breaks? If no, the second best thing we can do is to pause it by
libvirt, but it will still have caveats e.g. when libvirt is not around
to pause it.