* Michael S. Tsirkin (m...@redhat.com) wrote: > On Thu, Dec 03, 2020 at 11:43:41AM +0000, Dr. David Alan Gilbert wrote: > > * Michael S. Tsirkin (m...@redhat.com) wrote: > > > On Thu, Dec 03, 2020 at 11:32:53AM +0000, Daniel P. Berrangé wrote: > > > > On Thu, Dec 03, 2020 at 06:21:47AM -0500, Michael S. Tsirkin wrote: > > > > > On Wed, Dec 02, 2020 at 12:01:21PM +0000, Daniel P. Berrangé wrote: > > > > > > On Wed, Dec 02, 2020 at 06:37:46AM -0500, Michael S. Tsirkin wrote: > > > > > > > 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? > > > > > > > > > > > > If mgt attempt to pause an existing migration that hasn't finished > > > > > > the PCI unplug stage, then fail the pause request. > > > > > > > > > > Pause guest not migration ... > > > > > Might be tricky ... > > > > > > > > > > Let me ask this, why not just produce a warning > > > > > that migration wan't finish until guest actually runs? > > > > > User will then know and unpause the guest when he wants > > > > > migration to succeed ... > > > > > > > > A warning is going to be essentally invisible if the pause command > > > > succeeeds. > > > > > > > > Regards, > > > > Daniel > > > > > > I mean the situation here isn't earth shattering, an admin > > > created it. Maybe he will unpause shortly > > > and all will be well ... > > > > > > How about we make it possible for admin to detect that the > > > reason for migration not making progress is that it is > > > waiting for unplug? And maybe that guest is paused too? > > > > We already know that from the state of the VM. > > You don't know that migration is waiting for the guest > action, no. > > This is what we care about here right?
Yes we do, the migration status should be in 'MIGRATION_STATUS_WAIT_UNPLUG' (and that should have been notified as an event). Dave > > > > I just don't see how we can detect all cases and I am not > > > sure it is worth it to try and detect only some of them, > > > making users think they can rely on command failure to > > > detect them. > > > > Another way to solve this would be to remove the unplugging from the > > migration layer and leave it as a problem for the management layer to do > > the unplug. > > > > Dave > > > > > > > > > -- > > > > |: 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 :| > > > > > -- > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
