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

[Daniel P . Berrangé]

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.


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