On Mon, Apr 19, 2021 at 12:42 PM Daniel P. Berrangé <berra...@redhat.com> wrote:
>
> On Fri, Apr 16, 2021 at 12:28:01PM -0400, Eduardo Habkost wrote:
> > On Fri, Apr 16, 2021 at 09:33:28AM +0200, Vitaly Kuznetsov wrote:
> > > "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
> > >
> > > > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > >> On Thu, Apr 15, 2021 at 05:44:02PM +0200, Vitaly Kuznetsov wrote:
> > > >> > When a migration blocker is added nothing is reported to the user,
> > > >> > inability to migrate such guest may come as a late surprise. As a
> > > >> > bare
> > > >> > minimum, we can print a warning. To not pollute the output for
> > > >> > those, who
> > > >> > have no intention to migrate their guests, introduce '--no-migration'
> > > >> > option which both block the migration and eliminates warning from
> > > >>
> > > >> I wonder how this is actually going to work in practice ?
> > > >>
> > > >> At the time libvirt starts a guest, it has no idea whether the guest
> > > >> is likely to need migration 3, 6, 12, 24 months in to the future.
> > > >>
> > > >> IOW, we can't use a --no-migration flag and will be stuck with these
> > > >> warnings no mtter what.
> > > >>
> > > >> Is it possible to query the migration blockers via QMP ?
> > > >
> > > > It's possible to query the currently active ones, as of 6.0; from my
> > > > commit 3af8554bd068576b0399087583df48518a2a98f6 it appears in the
> > > > output of query-migrate in the 'blocked-reasons' list.
> > > >
> > > > The HMP equivalent is a64aec725ea0b26fa4e44f8b8b8c72be9aaa4230 showing:
> > > >
> > > > (qemu) info migrate
> > > > globals:
> > > > store-global-state: on
> > > > only-migratable: off
> > > > send-configuration: on
> > > > send-section-footer: on
> > > > decompress-error-check: on
> > > > clear-bitmap-shift: 18
> > > > Outgoing migration blocked:
> > > > Migration is disabled when VirtFS export path '/home' is mounted
> > > > in the guest using mount_tag 'fs'
> > > > non-migratable device: 0000:00:01.2/1/usb-serial
> > > >
> > >
> > > FWIW, this patch makes '--no-migration' an 'ultimate big hammer' so not
> > > matter how many blockers are there, the output will look like:
> > >
> > > (qemu) info migrate
> > > globals:
> > > store-global-state: on
> > > only-migratable: off
> > > send-configuration: on
> > > send-section-footer: on
> > > decompress-error-check: on
> > > clear-bitmap-shift: 18
> > > Outgoing migration blocked:
> > > Guest is not migratable ('--no-migration' used)
> >
> > I would change that. I expect "--no-migration" to only mean
> > "live migration not really needed", not "live migration should be
> > blocked".
> >
> > However, I still don't think libvirt should say "live migration
> > not needed" unconditionally (because this isn't always true). In
> > that case, we would need a different mechanism to silence the
> > warnings somehow.
> >
> > I would make live migration policy an enum, just to make sure
> > we are explicit about the requirements:
> >
> > - UNKNOWN: this is the current state in QEMU 6.0, where we don't
> > really know what the user expects.
> > This can be the default on existing versioned machine types,
> > just for compatibility.
> > I suggest making this print warnings for every migration
> > blocker (like this patch does).
> > I suggest deprecating this behavior as soon as we can.
> >
> > - PREFERRED: try to make the VM migratable when possible, but
> > don't print a warning or error out if migration is blocked.
> > This seems to be the behavior expected by libvirt today.
> >
> > - NOT_NEEDED: live migration is not needed, and QEMU is free to
> > enable features that block live migration or change guest ABI.
> > We can probably make this the default on machine types that
> > never supported live migration.
> >
> > - REQUIRED: live migration is required, and adding a migration
> > blocker would be a fatal error.
> > This is already implemented by --only-migratable.
> > I suggest making this the default on versioned machine types
> > after a few releases, and after deprecating UNKNOWN.
>
> I'm not a fan of tieing migration behaviour to machine type
> versioning as they are independant concepts. It is valid to
> want to use versioned machine types even if you never migrate,
> in order to keep stable guest ABI to avoid license activation
> checks in guest OS.
>
> Changing --only-migratable to a "--migration-policy preferred|required|none"
> is reasonable, but I think we should just have a fixed global default for
> it rather than trying to second-guess intentions.
Right, if we agree to make it opt-in we probably don't even need a
warning mode. `--only-migratable` should be enough. This means UNKNOWN
from my list above wouldn't exist, and the existing default is already
PREFERRED (which is the one expected by libvirt today).
--
Eduardo
