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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
