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