Daniel P. Berrangé <berrange@xxxxxxxxxx> writes: > On Wed, Mar 20, 2019 at 07:46:33AM +0100, Markus Armbruster wrote: >> We're going in circles. Igor keeps telling you QEMU needs to shed dead >> weight, badly. In Igor's words: >> >> We really need to figure out how to introduce breaking change on >> management (CLI) side* in QEMU and make it digestible for libvirt >> and others. >> (* at least for new machine types). >> >> You keep telling us QEMU can't ever deprecate stuff libvirt uses, >> because libvirt promised forward and backward compatibility forever. > > Note that libvirt didn't want to promise compatibility with live > migration from new -> old libvirt. We did break this a few times > in the past, and we received very clear feedback that users/mgmt > apps don't want their live migration to be broken in this way. > >> I'm with Igor on this one. I'm all for QEMU going the extra mile to >> help libvirt, simply because that helps a very large fraction of our >> users. I'm now asking libvirt to extend the courtesy back to QEMU. > > This isn't about helping libvirt - this is about helping the users of > libvirt & QEMU, We're in violent agreement on this point. However, ... > who *want* this back compatibility to be able to live > migrate their VMs in both directions. ... the users who want this are not the only users who matter, and I doubt even they want it at any cost. When dragging around a bad idea forever is expensive, we need a way to phase it out in an orderly manner. Similarly, when defaults go bad, we need a way to transition to better ones. QEMU has a way: versioned machine types. You've told us not to use them for that, because (if I understood you correctly) it won't work when a live migration's destination runs a sufficiently outdated libvirt. So, it's not just "we must maintain live migration compatibility backwards and forwards, forever, and at any cost", it's "the same, regardless of libvirt version". Sorry, that feels like at least one bridge too far. I've said that before[*], but got no reply. Perhaps the proposal I made there is unworkable. I've been wrong before. All I want is ... > Any time libvirt has had problems > in this area we get bug reports requiring us to fix it. This is why we > don't want to do a change which would knowingly create a problem which > will result in more bugs being reported against libvirt/QEMU ... this: >> Please sit down and think earnestly about how to best soften the >> compatibility promise you made so you can cope with changes we feel QEMU >> has to make. > > Please don't blame libvirt for giving users the live migration > compatibility we have been asked to provide to them. Our users' wish for maximal migration compatibility is understandable. However, "maximal" comes at a price. Buy paying it uncritically, we rob other users (or perhaps even the same ones) of improvments we could've bought instead. Please sit down and think earnestly what could be done in libvirt to let QEMU use versioned machine types for deprecating features. Don't tell us "nothing can be done". That feels as if you were trying to take us hostage. It's not meant that way, but it feels that way. Tell us what could be done. Describe the drawbacks. Feel free to tell us why you'd rather not do it. We can take it from there. > QEMU can change its impl, but users none the less expect live > migration to remain compatible for their VMs. > > I did think initially we could do this by assocating the changed > syntax with the machine type, until I was reminded that this does > not work for the backwards compatibility direction, which users > and mgmt apps have required libvirt to support. [*] Message-ID: <871s3fxce6.fsf@xxxxxxxxxxxxxxxxxx> https://lists.nongnu.org/archive/html/qemu-devel/2019-03/msg03052.html -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
