[libvirt] [Qemu-devel] [PATCH v2] numa: warn if numa 'mem' option or default RAM splitting between nodes is used.

Wed Mar 20 15:21:02 UTC 2019

On Wed, Mar 20, 2019 at 11:46:20AM -0300, Eduardo Habkost wrote:
> On Wed, Mar 20, 2019 at 01:46:59PM +0000, Daniel P. Berrangé wrote:
> > On Wed, Mar 20, 2019 at 10:32:53AM -0300, Eduardo Habkost wrote:
> > > On Wed, Mar 20, 2019 at 11:51:51AM +0000, Daniel P. Berrangé wrote:
> > > > On Wed, Mar 20, 2019 at 11:26:34AM +0100, Igor Mammedov wrote:
> > > [...]
> > > > >     So it's rather questionable if we should care about arbitrarily old
> > > > >     libvirt with new QEMU in case of new machines (especially upstream).
> > > > 
> > > > As noted above, with the deprecation feature policy new QEMU is not
> > > > likely to be compatible with arbitrarily old libvirt, but can usually
> > > > be expected to be compatible with upto 12 month old libvirt in the
> > > > best case, unless libvirt is really slow at adapting to deprecation
> > > > warnings.
> > > > 
> > > > So the challenge with tieing it to the new QEMU machine type is that
> > > > machine type is potentially used by a libvirt upto perhaps 12 months
> > > > old.
> > > > 
> > > 
> > > I'd like to understand one assumption here: why exactly do we
> > > need to make (e.g.) libvirt 4.8.0 (Oct 2018) compatible with
> > > _all_ machine-types in QEMU 4.1 (~Aug 2019), including pc-4.1.0?
> > > People who need backwards compatibility already have a huge list
> > > of old machine-types to choose from.
> > > 
> > > After all, pc-4.1.0 is surely a new feature from QEMU that
> > > didn't exist previously.
> > 
> > The new machine type is reported as the default expansion of the
> > "pc" alias (or equivalently "q35"), so it will get used automatically
> > for any case where the mgmt app / admin has not explicitly requested
> > a versioned type.  Libvirt queries this info from QEMU so that it
> > will always use the latested versioned machine type unless overriden.
> > This was generally seen as a good thing, because new machine types
> > enable new desired tweaks which can improve performance or fix
> > bugs, and so on.
> 
> Understood.  Maybe we should rethink the current approach.  The
> mechanism for choosing the default machine-type should leave room
> for cases where the newest machine-type isn't compatible with
> current libvirt.  This way we won't need to wait for one year
> before using a new feature by default.
> 
> Let me understand the requirements & expectations here: do we
> really need to make libvirt 5.4.0 (May 2019) to automatically
> translate "pc" to pc-4.1.0 if running QEMU 4.1.0 (Aug 2019)?
> What would happen if libvirt 5.4.0 translated pc to pc-4.0.0
> (even if running QEMU 4.1.0), and libvirt 5.8.0 (Sep 2019)
> translated pc to pc-4.1.0?

Nothing would break if you did that. Libvirt explicitly always
expands "pc" to a versioned machine precisely so that it is not
vulnerable to changes in the expansion in future.

I don't know how we would actually achieve this in practice
though.

The naive approach would be for libvirt to simply not honour
the QEMU default machine type at all. Libvirt could simply
hardcode the expansion of "pc" to "pc-i440fx-X.Y" based on
the newest QEMU that exists at time of libvirt release.

This would work except for the fact that the long long distros
all fork QEMU and throwaway the standard versioned machine
types and create their own with different names.  So if
libvirt harcoded a desired machine type itself, upstream libvirt
would cease to work on those distros which is something we really
want to avoid. It created significant pain for us when libvirt
upstream was unable to work with the QEMU in RHEL-6 because it
needed various non-upstream hacks in order to deal with the
partiallly implemented QMP monitor.

I really wish distros would not fork the machine types in QEMU
but that boat has sailed long ago, and it would require much
better upstream testing to avoid it anyway :-(

> > > > Somehow the older libvirt has to know to use the new QEMU feature
> > > > "memdev" that wasn't present required for any of the machine types
> > > > it knew about when it was first released.
> > > > 
> > > > 
> > > > This could be solved if QEMU has some machine type based property
> > > > that indicates whether "memdev" is required for a given machine,
> > > > but crucially *does not* actually activate that property until
> > > > several releases later.
> > > > 
> > > > We're too late for 4.0, so lets consider QEMU 4.1 as the
> > > > next release of QEMU, which opens for dev in April 2019.
> > > > 
> > > > QEMU 4.1 could introduce a machine type property "requires-memdev"
> > > > which defaults to "false" for all existing machine types. It
> > > > could add a deprecation that says a *future* machine type will
> > > > report "requires-memdev=true".  IOW,  "pc-i440fx-4.1" and
> > > > "pc-i440fx-4.2 must still report "requires-memdev=false", 
> > > > 
> > > > Libvirt 5.4.0 (May 2019) can now add support for "requires-memdev"
> > > > property. This would be effectively a no-op at time of this libvirt
> > > > release, since no QEMU would be reporting "requires-memdev=true" 
> > > > for many months to come yet.
> > > > 
> > > > Now, after 2 QEMU releases with the deprecation wawrning, when
> > > > the QEMU 5.0.0 dev cycle opens in Jan 2020, the new "pc-i440fx-5.0"
> > > >  machine type can be made to report "requires-memdev=true".
> > > > 
> > > > IOW, in April 2020 when QEMU 5.0.0 comes out, "mem" would no
> > > > longer be supported for new machine types. Libvirt at this
> > > > time would be upto 6.4.0 but that's co-incidental since it
> > > > would already be doing the right thing since 5.4.0.
> > > > 
> > > > IOW, this QEMU 5.0.0 would work correctly with libvirt versions
> > > > in the range 5.4.0 to 6.4.0 (and future).
> > > > 
> > > > If a user had libvirt < 5.4.0 (ie older than May 2019) nothing
> > > > would stop them using the "pc-i440fx-5.0" machine type, but
> > > > libvirt would be liable to use "mem" instead of "memdev" and
> > > > if that happened they would be unable to live migrate to a
> > > > host newer libvirt which honours "requires-memdev=true"
> > > > 
> > > > 
> > > > So in summary the key to being able to tie deprecations to machine 
> > > > type versions, is for QEMU to add a mechanism to report the desired 
> > > > new feature usage approach against the machine type, but then ensure
> > > > the mechanism continues to report the old approach for 2 more releases.
> > > 
> > > This proposal seems to work, but I'm worried that the code in
> > > libvirt for using the new mechanism will be left completely
> > > unused and untested by our users for a whole year (until we
> > > release a QEMU version that sets requires-memdev=true).
> > 
> > Yes, that is a challenge. The risk is that libvirt thinks it
> > has adapted its code to only use memdev, but might have missed
> > a codepath & this won't be noticed immediately. Maybe there is
> > a way to get this exercised by automated CI where migration
> > compat is a non-issue.
> > 
> > > If a feature is deprecated, I would expect the management stack
> > > to stop using the deprecated feature by default as soon as
> > > possible, not 1 year after it was deprecated.
> > 
> > True, but the challenge here is that we need to stop using the
> > feature in a way that isn't going to break ability to live migrate
> > VMs spawned by previous versions of libvirt. Most of the time when 
> > we stop using a deprecated feature there isn't this complication, 
> > so there is zero downside to using the new feature immediately.
> 
> Keeping the ability to live migrate to older libvirt is easy to
> implement on older machine-types.  The problem is more complex
> only because we want libvirt to use machine-types that didn't
> exist yet when libvirt was released.  I still don't know if this
> is a requirement we really want to keep.

As above, I don't think it is important to keep it, but I don't have any
good ideas about how to get different libvirt versions to use a different
machine type version.

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