On Tue, 2019-04-30 at 14:27 +0100, Daniel P. Berrangé wrote: > On Tue, Apr 30, 2019 at 03:22:03PM +0200, Andrea Bolognani wrote: > > Anyway, the rest of the replies were generated from QEMU binaries > > built on RHEL, and on non-x86 architectures too, so we don't have to > > worry about those accidentally containing Xen support :) > > IMHO we should not generate standard replies from the QEMU binaries > from RHEL, unless we are specifically looking to cover the RHEL fork > of QEMU. RHEL cannot be consistently assumed to match upstream QEMU > behaviour due to RHEL's fairly aggressive patch backporting. The > Fedora builds are essentially vanilla upstream code, so a better bet > for generic capabilities. I built upstream QEMU *on* RHEL, then generated replies from those binaries. Whatever patching is done to QEMU in RHEL, it does not at any point enter the picture. I could conceivably provision the same machines with Fedora and build QEMU + libvirt there, but that would be quite a bit of extra work on top of something that's not fun nor quick to do in the first place, so I'd rather keep using RHEL as the build OS. I'm also unconvinced the result would be substantially different. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
