On Wed, Mar 20, 2019 at 01:46:59PM +0000, Daniel P. Berrangé wrote: > On Wed, Mar 20, 2019 at 10:32:53AM -0300, Eduardo Habkost wrote: > > On Wed, Mar 20, 2019 at 11:51:51AM +0000, Daniel P. Berrangé wrote: > > > 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. > > > > > > > I'd like to understand one assumption here: why exactly do we > > need to make (e.g.) libvirt 4.8.0 (Oct 2018) compatible with > > _all_ machine-types in QEMU 4.1 (~Aug 2019), including pc-4.1.0? > > People who need backwards compatibility already have a huge list > > of old machine-types to choose from. > > > > After all, pc-4.1.0 is surely a new feature from QEMU that > > didn't exist previously. > > The new machine type is reported as the default expansion of the > "pc" alias (or equivalently "q35"), so it will get used automatically > for any case where the mgmt app / admin has not explicitly requested > a versioned type. Libvirt queries this info from QEMU so that it > will always use the latested versioned machine type unless overriden. > This was generally seen as a good thing, because new machine types > enable new desired tweaks which can improve performance or fix > bugs, and so on. Understood. Maybe we should rethink the current approach. The mechanism for choosing the default machine-type should leave room for cases where the newest machine-type isn't compatible with current libvirt. This way we won't need to wait for one year before using a new feature by default. Let me understand the requirements & expectations here: do we really need to make libvirt 5.4.0 (May 2019) to automatically translate "pc" to pc-4.1.0 if running QEMU 4.1.0 (Aug 2019)? What would happen if libvirt 5.4.0 translated pc to pc-4.0.0 (even if running QEMU 4.1.0), and libvirt 5.8.0 (Sep 2019) translated pc to pc-4.1.0? > > > 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. > > > > This proposal seems to work, but I'm worried that the code in > > libvirt for using the new mechanism will be left completely > > unused and untested by our users for a whole year (until we > > release a QEMU version that sets requires-memdev=true). > > Yes, that is a challenge. The risk is that libvirt thinks it > has adapted its code to only use memdev, but might have missed > a codepath & this won't be noticed immediately. Maybe there is > a way to get this exercised by automated CI where migration > compat is a non-issue. > > > If a feature is deprecated, I would expect the management stack > > to stop using the deprecated feature by default as soon as > > possible, not 1 year after it was deprecated. > > True, but the challenge here is that we need to stop using the > feature in a way that isn't going to break ability to live migrate > VMs spawned by previous versions of libvirt. Most of the time when > we stop using a deprecated feature there isn't this complication, > so there is zero downside to using the new feature immediately. Keeping the ability to live migrate to older libvirt is easy to implement on older machine-types. The problem is more complex only because we want libvirt to use machine-types that didn't exist yet when libvirt was released. I still don't know if this is a requirement we really want to keep. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
