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 <ebl...@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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
