On 03/06/2013 03:23 PM, Skardal, Harald wrote: In general, both upstream qemu and upstream libvirt strive to be compiled out-of-the-box on as many platforms as possible; I'm not sure whether modern qemu would compile on RHEL 5, but I regularly test that upstream libvirt builds on RHEL 5. On the other hand, the moment you install self-built binaries instead of the version shipped by the distro, you no longer get support from the distro. If that's a risk you're willing to take, then using newer versions is fine; but you may want to think twice about using your support contract to ask Red Hat to backport a particular feature you want into the distro where it would be fully supported, instead of taking on the support burden onto your own shoulders. When I do my own testing of upstream libvirt on random platforms (and this includes RHEL 5 and RHEL 6.4), I target things against the platform qemu rather than the latest qemu release. In fact, that's one of the goals of libvirt - to provide a stable interface so that things using the libvirt interface behave the same regardless of the underlying differences between the distro backports of older versions, vs. the bleeding edge of upstream versions. But generally, if you are going to install a self-built binary to get a feature that the distro was unwilling to backport, you might as well install all of the virt stack. Also, while new libvirt with old qemu is supposed to work, old libvirt mixed with new qemu is liable to have problems. So upgrading qemu in isolation without upgrading libvirt is riskier than upgrading libvirt in isolation without upgrading qemu. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org