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.

> > My understanding talking with Laine is that they use this functionality
> > by default for migration, saving, etc, i.e. it is not an isolated case.
> 
> Yep,  save-to-disk always runs in the paused state, and migration is
> also paused by default unless the mgmt app explicitl asks for live
> 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 :|


Reply via email to