On Tue, 2018-04-03 at 15:59 +0100, Daniel P. Berrangé wrote: > On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote: > > Most of the compelling features introduced by any libvirt release > > require the corresponding QEMU feature to be available. And, as > > I've argued elsewhere in the thread, replacing the vendor QEMU and > > libvirt with recent upstream releases is much easier than replacing > > other components of the OS, most notably the kernel (and hence KVM). > > There are plenty of features we introduce that don't require new software > versions. They may not be as frequent, but there are still compelling. How many of those would be compelling enough to convince users to step outside of the comfort zone (and probably support terms) of vendor-provided packages and roll their own virtualization stack from upstream sources? I reckon not that many. But if you add a newer QEMU to the mix, then that's a wholly different value proposition. > > As I have argued elsewhere in the thread, I think we can still > > support two major releases of the *base system*, but we should > > drop support for the downstream virtualization stack (eg. QEMU) > > a reasonable, short-ish time after the vendor itself has stopped > > updating it. > > I don't think the "base" vs "virtualization" stack distinction is a good > thing to base our decisions on. In RHEL-5 there was no distinction in > this at all - virt was a core part of every RHEL subscription. In RHEL-7 > meanwhile the base system includes an ancient version of QEMU (1.5.3) > that everyone gets, while another add-on gives you new QEMU. I'll bet > future RHEL will be different again. My point is that QEMU and libvirt move much faster than eg. glibc, so while it's very possible to target RHEL 6's userland without bending over backwards and introducing or keeping around heaps of compatibility code, the same is not necessarily true for RHEL 6's QEMU, as evidenced by Jano's series. RHEL 7's virtualization stack is still in a place where new features are being introduced, as shown by the fact that every minor release brings in a new libvirt release: that makes it a reasonable target for the upstream project. RHEL 6 has been standing still for a while now, so it's okay for us to move on. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
