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.
Migration needs to strive to be transparent to the guest workload
and IMHO having the guest workload selectively executing and
selectively blocked is not transparent enough. It should require
a user opt-in for this kind of behaviour.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|