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

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

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