On Fri, Nov 06, 2015 at 07:42:35AM +0100, Peter Krempa wrote:
On Thu, Nov 05, 2015 at 17:33:52 +0000, Daniel Berrange wrote:
The patches for introducing virtlogd will be significantly simplified if we don't need to worry about parsing stderr during startup. This is required prior to QEMU 0.11 so that we can get the dyanamically allocated /dev/pty/NNN paths.
I'm so glad to see something like this. Not only to simplify adding virtlogd but also we will be able to remove some _very_ old cruft.
The QEMU 0.12.1 release was shipped in RHEL-6 vintage distros and is already quite old, so seems like a fair target version to aim for as the minimum required.
I'd like to add that I think this is still too vintage. It's now almost 6 years from that point:
commit 6c412ddf1cc0c41a7c36064a4a9c428e99c52ff8 Author: Anthony Liguori <aliguori@us.ibm.com> Date: Sat Dec 19 08:23:00 2009 -0600
Update for 0.12.0 release
and right after that:
commit fe1b69708c72b163d3acdf2bb012e169d2d3dda0 Author: Anthony Liguori <aliguori@us.ibm.com> Date: Sat Dec 19 19:31:18 2009 -0600
Update version and changelog for 0.12.1
The initial qemu version in RHEL-6 was indeed 0.12.1, but if you look at the current state of it you'll notice that it was patched quite a lot so it rather stopped to resemble the 0.12 release and was really holding up with upstream for quite a while. Libvirt was even rebased during the current lifetime of rhel/centos 6 distros to 0.10.2 (and it has quite a few patches on top of that too). Libvirt 0.10.2 was released almost 3 years after qemu 0.12.0:
Although QEMU 0.12.1 in RHEL6 is heavily patched with feature backports, when picking a target min version, I'm really lookng at the approximate "vintage" rather than the specific featureset of RHEL6 QEMU. As another benchmark of the same vintage, Debian Squeeze has QEMU 0.12.5. I just round off the micro version, so pick 0.12.0.
commit f8fbeb50d52520a109d71c8566fed2ea600650ec Author: Daniel Veillard <veillard@redhat.com> Date: Mon Sep 24 12:06:05 2012 +0800
Release of libvirt-0.10.2
So while having rhel-6 as a support target might look cool, nobody would actually use such old code anyways, since they can get tested and patched packages with a ton of new features.
I am rather conservative about pushing min versions, since IME many corporates tend to stick with ancient versions of software for much longer than people tend to realize. At this time RHEL-6 is almost certainly the largest deployment / user base for libvirt / QEMU out of all the RHEL versions. It will be a while before RHEL-7 overtakes it to become the dominant RHEL platform. As such I think it is important that libvirt upstream continue to be buildable against RHEL-6 and target the QEMU 0.12.x series that includes (even though RHEL6 QEMU is rather a frakenmonster of backports at this time) 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 :|