qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] numa: warn if numa 'mem' option or default R


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v2] numa: warn if numa 'mem' option or default RAM splitting between nodes is used.
Date: Wed, 20 Mar 2019 11:46:20 -0300
User-agent: Mutt/1.10.1 (2018-07-13)

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?


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

-- 
Eduardo



reply via email to

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