[libvirt] [PATCH 0/5] tests: Refresh/add capabilities for QEMU 4.0.0

[Daniel P. Berrangé]

On Tue, Apr 30, 2019 at 03:41:18PM +0200, Andrea Bolognani wrote:
> 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.

Ah, that's reasonably safe right now, as QMP is largely static. So
even if features are disabled at build time, most stuff still appears
in QMP.  QMP is getting more dynamic though, so that it respects
build time choices better. Thus in future we should aim to ahve
a consistent (maximum) set of features enabled in QEMU builds.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|