qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH RFC] migration: warn about non-migratable configurations unle


From: Eduardo Habkost
Subject: Re: [PATCH RFC] migration: warn about non-migratable configurations unless '--no-migration' was specified
Date: Thu, 15 Apr 2021 12:30:11 -0400

On Thu, Apr 15, 2021 at 12:04 PM 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.

I believe the libvirt API could be extended so applications can
indicate that migration is not a required feature. This would let QEMU
automatically enable useful but non-migration-friendly features. For
example, I would expect "-cpu host" to become the default CPU model if
--no-migration is specified.

>
> IOW, we can't use a --no-migration flag and will be stuck with these
> warnings no mtter what.

The expected behavior of the libvirt API is to create migratable VMs
by default, isn't it? This means it would be valid for libvirt to use
"--only-migratable" by default.

If libvirt can't use "--only-migratable" by default, I would say it's
a deficiency of the libvirt API that needs to be addressed.

>
> Is it possible to query the migration blockers via QMP ?

I don't think it is, but we can add that if it's useful for libvirt.

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

Cool!

Will the API include all warnings printed by QEMU to stderr?

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

--
Eduardo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]