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

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.

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.