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

Daniel P. Berrangé berrange at redhat.com
Tue Apr 3 13:49:34 UTC 2018


On Tue, Apr 03, 2018 at 12:57:45PM +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.

The scenario wrt JSON monitor support was also the case when RHEL-6.0 first
came out. It is easily addressed with a tweak to the version number check.
We eventually added that RHEL-6 custom check to libvirt upstream too, but
then later reverted it. Thus whether we have that tweaked version check in
upstream or not, doesn't change whether we should consider the RHEL-6
vintage to be a supported target or not IMHO. 

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

Libvirt's goal has always been to enable developers to use new libvirt
with previous versions of QEMU. We have *never* said that when you deploy
new libvirt on a platform, you must also update QEMU. The only requirement
has been that you must have the minimum declared version number, never
latest upstream QEMU.

It is entirely reasonable to want to use a new libvirt without updating
the QEMU version, because the QEMU/KVM/kernel triple is what provides the
guest OS / driver compatibility testing & thus is the most compelling part
of the supported platform RHEL provides. 

That said we are of course not going to support RHEL-6 forever and it is
reasonable to consider when the cut-off point is for the platform as a
whole. Historically we have considered 2 major RHEL releases to be the
target. IOW drop RHEL-6 when RHEL-8 appears. Maybe that is too long and
we would be better saying we'll aim for an N year overlap of support for
major RHEL releases, for a value of N that's less than the time delta
between RHEL 7 & 8. 

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




More information about the libvir-list mailing list