[libvirt] Dropping RHEL-6/CentOS-6 support

[Daniel P. Berrange]

On Tue, Feb 09, 2016 at 03:15:31PM +0100, Peter Krempa wrote:
> On Tue, Feb 09, 2016 at 12:59:45 +0000, Daniel Berrange wrote:
> > On Tue, Feb 09, 2016 at 01:56:19PM +0100, Michal Privoznik wrote:
> > > On 09.02.2016 13:52, Daniel P. Berrange wrote:
> > > > On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote:
> 
> ...
> 
> > > > IMHO it is well premature to stop caring about RHEL-6. We only just
> > > > dropped support for RHEL-5, but RHEL-6 is very much still a widely
> > > > used platform and will continue to be so for a good while yet.
> > > 
> > > Sure, but I'm not talking about downstream support rather than upstream
> > > one. Or are you saying that nor upstream should drop RHEL-6?
> > 
> > I'm talking about upstream too. Libvirt is *not* about only supporting the
> > latest cutting edge distros. We aim to support a broad range of distros
> > that are currently widely in use. RHEL-6 most certainly falls under that
> > umbrella, and upstream libvirt must *not* drop it as a targetted platform.
> 
> The qemu in rhel6 has diverged so much from it's original code base that
> libvirt is carrying hacks to make it work:
> 
> commit ff88cd590572277f10ecee4ebb1174d9b70fc0d7
> Author: Eric Blake <eblake at redhat.com>
> Date:   Wed Jan 25 21:33:21 2012 -0700
> 
>     qemu: support qmp on RHEL/CentOS qemu
>     
>     I'm getting tired of remembering to backport RHEL-specific
>     patches when building upstream libvirt on RHEL 6.x or CentOS.
>     All the affected versions of RHEL qemu-kvm have backported
>     enough patches to a) make JSON useful, and b) modify the
>     -help text to mention libvirt as the preferred interface;
>     which means this string in the help output is a reliable
>     indicator that we can outsmart a strict version check,
>     even when upstream qemu 0.12 lacked the needed features.
> 
> This code looks specifically for the string "libvirt" which was added by
> the downstream version. The upstream libvirt doesn't carry a few
> downstream patches that make certain features work though.
> 
> With the above code we are able to run with the qemu, but I'd not really
> want to call it that we support it. We merely put it on life support so
> that it works.
> 
> Additionally you don't really gain much with just using new libvirt, and
> when you want to compile new qemu you might as well as use a completely
> new system as well. Using it on Centos6 would not really add any benefit
> in this regard.
> 
> The above is to point out that users of Centos 6 usually won't compile
> libvirt and qemu from sources since they want to enjoy benefits of a
> stable platform with tested software. Sticking upstream versions on top
> of that defies the purpose.

NB, RHEL is not the only distro we target - when I say we should target
RHEL-6 as the oldest platform, I use that mostly as an example of the
approximate vintage. I would consider any still supported Debian version
that is the same age as RHEL-6 to be a valid platform too, likeise for
Ubuntu LTS releases or SLES. At least some of those will using fairly
vanilla QEMU version without feature backports.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|