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

[Igor Mammedov]

On Wed, 20 Mar 2019 15:24:42 +0000
Daniel P. Berrangé <berrange at redhat.com> wrote:

> On Wed, Mar 20, 2019 at 04:20:19PM +0100, Igor Mammedov wrote:
> > > 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"  
> > I failed to parse this section in connection '^' underlined part,
> > I'm reading 'no longer be supported' as it's not possible to start
> > QEMU -M machine_foo.requires-memdev=true with 'mem' option.
> > Is it what you've meant?  
> 
> I wasn't actually meaning QEMU to forbid it when i wrote this, 
> but on reflection, it would make sense to forbid it, as that
> would avoid the user getting into a messy situation with 
> versions of libvirt that predate knowledge of the requires-memdev
> property.
Forbidding is my goal as it (at least for new machine types)
 - removes possibility of mis-configuration 
 - allows in new machine to switch to frontend-backend memory model
   in clean way consolidating/unifying memory management
   (i.e. not need to map 'mem' to memdev, which from recent
    migration experiment appears to be impossible to do reliably)
 - remove someday 'mem' and all related code from QEMU once
   the last old machine where it was possible to use if deprecated
   (well, it's rather far fetched goal for that we need to come up
    with schedule/policyhow/when we would deprecate old machines).


> > > 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.  
> > 
> > so that makes QEMU deprecation period effectively 3 releases (assuming 
> > 4 months cadence).  
> 
> There's a distinction betweenm releases and development cycles here.
> The deprecation policy is defined as 2 releases, which means between
> 2 and 3 development cycles depending on when in the dev cycle the
> deprecation is added (start vs the end of the dev cycle)
> 
> Regards,
> Daniel