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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Daniel P. Berrangé (berrange@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
    
Dave

> Libvirt recently introduced a new API 'virDomainGetMessages' which
> lets us report a list of human targetted message strings against
> a guest. We use it for reporting when an operation has tainted
> a guest, and also use it for reporting when a deprecated QEMU
> feature is used.  We could use it to report any migration
> blockers that exist.
> 
> These are visible from 'virsh dominfo $guestname' and could also
> be displayed by a mgmt application.
> 
> NB, the messages are intentionally declared opaque strings, so
> mgmt apps shouldn't try to parse them. They merely know whether
> the count is non-zero for any given message class.
> 
> 
> 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 :|
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK