On Wed, Dec 02, 2020 at 11:26:39AM +0000, Daniel P. Berrangé wrote: > On Wed, Dec 02, 2020 at 06:19:29AM -0500, Michael S. Tsirkin wrote: > > On Wed, Dec 02, 2020 at 10:55:15AM +0000, Daniel P. Berrangé wrote: > > > On Wed, Dec 02, 2020 at 11:51:05AM +0100, Juan Quintela wrote: > > > > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > > > On Wed, Dec 02, 2020 at 05:31:53AM -0500, Michael S. Tsirkin wrote: > > > > >> On Wed, Dec 02, 2020 at 10:27:18AM +0000, Daniel P. Berrangé > > > > >> wrote: > > > > >> > On Wed, Dec 02, 2020 at 05:13:18AM -0500, Michael S. Tsirkin wrote: > > > > >> > > On Wed, Nov 18, 2020 at 09:37:22AM +0100, Juan Quintela wrote: > > > > >> > > > If we have a paused guest, it can't unplug the network VF > > > > >> > > > device, so > > > > >> > > > we wait there forever. Just change the code to give one error > > > > >> > > > on that > > > > >> > > > case. > > > > >> > > > > > > > >> > > > Signed-off-by: Juan Quintela <quint...@redhat.com> > > > > >> > > > > > > >> > > It's certainly possible but it's management that created > > > > >> > > this situation after all - why do we bother to enforce > > > > >> > > a policy? It is possible that management will unpause immediately > > > > >> > > afterwards and everything will proceed smoothly. > > > > >> > > > > > > >> > > Yes migration will not happen until guest is > > > > >> > > unpaused but the same it true of e.g. a guest that is stuck > > > > >> > > because of a bug. > > > > >> > > > > > >> > That's pretty different behaviour from how migration normally > > > > >> > handles > > > > >> > a paused guest, which is that it is guaranteed to complete the > > > > >> > migration > > > > >> > in as short a time as network bandwidth allows. > > > > >> > > > > > >> > Just ignoring the situation I think will lead to surprise apps / > > > > >> > admins, > > > > >> > because the person/entity invoking the migration is not likely to > > > > >> > have > > > > >> > checked wether this particular guest uses net failover or not > > > > >> > before > > > > >> > invoking - they'll just be expecting a paused migration to run > > > > >> > fast and > > > > >> > be guaranteed to complete. > > > > >> > > > > > >> > Regards, > > > > >> > Daniel > > > > >> > > > > >> Okay I guess. But then shouldn't we handle the reverse situation too: > > > > >> pausing guest after migration started but before device was > > > > >> unplugged? > > > > >> > > > > > > > > > > Thinking of which, I have no idea how we'd handle it - fail > > > > > pausing guest until migration is cancelled? > > > > > > > > > > All this seems heavy handed to me ... > > > > > > > > This is the minimal fix that I can think of. > > > > > > > > Further solution would be: > > > > - Add a new migration parameter: migrate-paused > > > > - change libvirt to use the new parameter if it exist > > > > - in qemu, when we do start migration (but after we wait for the unplug > > > > device) paused the guest before starting migration and resume it after > > > > migration finish. > > > > > > It would also have to handle issuing of paused after migration has > > > been started - delay the pause request until the nuplug is complete > > > is one answer. > > > > Hmm my worry would be that pausing is one way to give cpu > > resources back to host. It's problematic if guest can delay > > that indefinitely. > > hmm, yes, that is awkward. Perhaps we should just report an explicit > error then.
Report an error in response to which command? Do you mean fail migration? > In normal cases this won't happen, as unplug will have > easily completed before the mgmt app pauses the running migration. > In broken/malicious guest cases, this at least ives mgmt a heads up > that something is wrong and they might then decide to cancel the > migration. > > > 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 :|
