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

[Daniel P. Berrangé]

On Tue, Apr 03, 2018 at 01:23:15PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
> > On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > > It's been a while since we last bumped the minimum QEMU version.
> > > > Let's get rid of -help parsing and bring our test suite closer
> > > > to real world usage by implying lots of capabilities.
> > > 
> > > NACK, this is effectively dropping support for RHEL-6 without explicitly
> > > saying you're doing this.
> > 
> > Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
> > least from the latest releases) as it diverged significantly from
> > upstream. Upstream will e.g. not be able to see that JSON monitor needs
> > to be used with that old version or that the downstream implementations
> > of some commands need to be used.
> > 
> > Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
> > argument that you might want new features with the "stability" of the
> > old OS is wrong if you pull in bugs from upstream.
> 
> This makes sense to me. One of the (several) times the topic of
> dropping support for older OS, one of the arguments against it was
> that downstream vendors were building products on top of RHEL 6,
> but at the same time needed newer QEMU / libvirt features, so they
> pulled those in from upstream.
> 
> 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. 

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

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