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

[Pavel Hrdina]

On Tue, Apr 03, 2018 at 02:49:34PM +0100, Daniel P. Berrangé wrote:
> 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. 

That sounds reasonable, I would even vote for 2 year overlap, but
that would be probably way too strict so 3 year overlap is a good
compromise.  This would mean that we can drop support for RHEL < 7,
SLES < 12 and Debian < 8.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180403/7fa823c7/attachment-0001.sig>