Re: [PATCH RFC] migration: warn about non-migratable configurations unless '--no-migration' was specified

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Apr 20, 2021 at 03:10:44PM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabkost@redhat.com) wrote:
> > On Tue, Apr 20, 2021 at 12:51:43PM +0100, Dr. David Alan Gilbert wrote:
> > > I prefer things that are fairly obvious without needing to look at the
> > > documentation until you want the detail.
> > > 
> > > > - NONE: live migration is not needed, and device or machine code
> > > >   is allowed to enable features that block live migration or
> > > >   change guest ABI.
> > > >   (Not implemented yet)
> > > > 
> > > > - PREFERRED: machine and device code should try to make the VM
> > > >   migratable when possible, but won't emit a warning or error out
> > > >   if migration is blocked.
> > > >   (Current default behavior)
> > > > 
> > > > - REQUIRED: live migration support is required, and adding a
> > > >   migration blocker will be an error.
> > > >   (Implemented today by --only-migratable)
> > > 
> > > How about
> > >   -migratable blocked
> > >      Live migration is not allowed; an outbound migration will fail
> > 
> > "none" and NOT_NEEDED above were about letting QEMU automatically
> > enable features that block live migration or change guest ABI.
> > 
> > If that's implied by "blocked", I'd like to get that documented
> > explicitly.  If that's not implied by "blocked", I don't
> > understand what's the use case for "blocked".
> 
> My 'blocked' is stronger - migration is hard disabled by a blocker
> always; it's for (rare) cases where the user wants to stop a migration
> happening, even if qemu believes it can do it.
> 
> > > 
> > >   -migratable allowed
> > >      Live migration is allowed, but some devices/options may block
> > >      it if they're unable to migrate [current default]
> > 
> > "preferred" above was about QEMU trying to keep live migration
> > working as much as possible.  That's something we all expect QEMU
> > to do, but it's not documented anywhere.
> > 
> > If that's implied by "allowed", I'd like to get that documented
> > explicitly.  If that's not implied by "allowed", then we have a
> > problem.
> 
> My difficulty by your definition is I don't understand what
> 'working as much as possible' means - that's the current behaviour
> as I understand it.   I think mine is more explicit.

I think it helps to illustrate examples. The obvious case is where
thre are new kernel features QEMU wants to use. Normally we try to
avoid using them because that reduces potential targets for
migration to those with the same kernel or newer.

So a "preferred" / "allowed" mode would avoid automagically using
new host kernel features, while a "blocked" / "none" mode would
be free to use any kernel features

> > > 
> > >   -migratable warn
> > >       Live migration is allowed, but if some device/option is
> > >       unable to migrate, migration will be blocked and a warning
> > >       printed
> > 
> > This makes sense, but I don't think we need to support this use
> > case.
> 
> I thought that was exactly what Vitaly's patch tried to do?

Yep, but I'm sceptical how useful it actually is in practice.

Whether migration is blocked at the time the VM starts is not
really important, because VM configuration can be changed
at runtime, making any warnings obsolete/inaccurate for anyone
reading them after the fact.

> 
> > > 
> > >   -migratable required
> > >       Live migration is allowed, attempting to add a device or
> > >       enable an option that can't migrate will fail. [--only-migratable]
> > 
> > This matches "required" above.
> 
> Dave
> 
> 
> > -- 
> > Eduardo
> -- 
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 

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