[libvirt] [PATCH 0/7] Drop support for QEMU < 0.12.0

Eric Blake eblake at redhat.com
Thu Nov 5 18:05:53 UTC 2015

On 11/05/2015 10:47 AM, Cole Robinson wrote:
> On 11/05/2015 12:33 PM, Daniel P. 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.
>> 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.
> Up next... drop support for building on RHEL-5 ? :) Would mean we could
> simplify the RPM spec quite a bit

Upstream qemu 2.4 has already effectively dropped support for RHEL 5,
and the upcoming qemu 2.5 takes that even further by bumping minimum
glib and python requirements so that it is no longer possible to develop
qemu out of the box on RHEL 5.

My argument is that libvirt should be buildable out of the box on any
platform where its underlying hypervisor support is also buildable out
of the box, as follows:

There are two types of users that stick to older systems:

1. You are using an older system on purpose, for its stability, and you
don't care about newer features.  You are thus relying on your vendor to
ship you stable qemu and libvirt, and won't be building out of the box.
 Upstream may not build on your system, but you don't care, because your
vendor is backporting the relevant upstream patches to your older setup.

2. You are using an older system for its stability elsewhere, but you
want to augment that system to also take advantage of newer upstream
features faster than your vendor is doing in their pre-built versions.
As long as the entire stack can be built out of the box on your system,
then you do not need your vendor for your virt stack.  But you are also
admitting that you don't need your vendor.  As soon as one part of the
stack no longer builds out of the box, you probably aren't going to
build any of the rest of the stack.  But you've already proven you can
build the versions you need, so you no longer need to track upstream.
If upstream comes out with a feature you need, then it is time to
consider upgrading, and putting the burden of stability back on your
vendor, than to manage an ever-increasing set of things that no longer
build by yourself.

All other users are using newer systems.  Here, whether relying on the
vendor to backport stable patches, or building out of the box, it is not
a problem because the package can still be built on that system's

So I would be in favor of dropping RHEL 5 as an out-of-the-box build
platform for upstream libvirt.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151105/b7ec3fb9/attachment-0001.sig>

More information about the libvir-list mailing list