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 ... > > -- > > |: 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 > > :|
