[libvirt] [PATCH 00/44] Require QEMU 1.3.0 or newer

[Daniel P. Berrangé]

On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 15:00 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 03, 2018 at 01:23:15PM +0200, Andrea Bolognani wrote:
> > > Bumping our minimum QEMU version wouldn't affect that kind of
> > > scenario, as long as we keep making sure libvirt itself builds on
> > > RHEL 6 - which we already do as part of the CI effort.
> > 
> > Building on RHEL-6  without supporting QEMU/KVM from RHEL-6 is pointless,
> > you might as well just drop the whole platform. It is not a compelling
> > story to tell users you can build on RHEL-6 but you won't be able to use
> > the hypervisor from RHEL-6, as the kernel+KVM+QEMU triple is the compelling
> > part from guest OS pov.
> 
> 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.


> > > Honestly, who in the world absolutely needs the very last libvirt
> > > while at the same time being stuck with QEMU < 1.3.0? However you
> > > slice it, that doesn't sound like a remotely sane scenario.
> > 
> > The version of libvirt that ships with RHEL-6 is very old, lacking many
> > features and certainly hasn't had all relevant bug fixes backported.
> > It is certaily relevant to wish to use new libvirt with old QEMU for
> > "some" period of time. The question is how far back to go. Previously
> > we've said 2 major RHEL releases was the target
> > 
> > The tension is that the gap between RHEL-5 and RHEL-6 and RHEL-7 was
> > approx 3 years. If that pattern had carried on RHEL-8 would have arrived
> > in 2017, and we would have thus culled RHEL-6 support some time last
> > year. This is a sign that instead of saying 2 major releases, we should
> > instead define "NN" years of overlapping support for a value of NN
> > that is 2 or 3. ie drop RHEL-6 as a target after RHEL-7 has been released
> > for NN years.
> 
> 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.

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