Daniel P. Berrangé <berra...@redhat.com> writes: > On Mon, Oct 23, 2023 at 05:35:45PM -0300, Fabiano Rosas wrote: >> Add a capability that allows the management layer to delegate to QEMU >> the decision of whether to pause a VM and perform a non-live >> migration. Depending on the type of migration being performed, this >> could bring performance benefits. > > I'm not really see what problem this is solving. >
Well, this is the fruit of your discussion with Peter Xu in the previous version of the patch. To recap: he thinks QEMU is doing useless work with file migrations because they are always asynchronous. He thinks we should always pause before doing fixed-ram migration. You said that libvirt would rather use fixed-ram for a more broad set of savevm-style commands, so you'd rather not always pause. I'm trying to cater to both of your wishes. This new capability is the middle ground I came up with. So fixed-ram would always pause the VM, because that is the primary use-case, but libvirt would be allowed to say: don't pause this time. > Mgmt apps are perfectly capable of pausing the VM before issuing > the migrate operation. > Right. But would QEMU be allowed to just assume that if a VM is paused at the start of migration it can then go ahead and skip all dirty page mechanisms? Without pausing, we're basically doing *live* migration into a static file that will be kept on disk for who knows how long before being restored on the other side. We could release the src QEMU resources (a bit) earlier if we paused the VM beforehand. We're basically talking about whether we want the VM to be usable in the (hopefully) very short time between issuing the migration command and the migration being finished. We might be splitting hairs here, but we need some sort of consensus.
