Bug 1468043

Summary: Backport "Use more data for comparing CPUs" commit series to work correctly with qemu 2.9.0+
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 26CC: agedosier, berrange, clalancette, crobinso, itamar, kparal, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-03 21:13:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Adam Williamson 2017-07-05 20:57:54 UTC 
This is a continuation of https://bugzilla.redhat.com/show_bug.cgi?id=1467599 , which covers an issue between qemu 2.9.0+ and libvirt 3.2 in how CPU capability querying and comparison is done that can cause VMs to fail to run with certain CPU settings on certain systems.

For the Fedora 26 release we are likely to deal with this via a qemu workaround initially, and the original bug is now covering that qemu workaround. But we don't want that to be the permanent fix; it seems better to backport the commits that make this work correctly with qemu 2.9.0+ from libvirt 3.3.

Laine says the following commits were backported to the RHEL 7.4 package (presumably to address the same problem):

05e91c79f19e0be96526098d58a3498dac3f8529
d84b93fad51b190238e18b1daac82ea6e28869e9
00e0cbcb567a57c7b5a145d7fd3fb662779f6bec
bffc3b9fe501ff122ad81ddf42ecdb69f70ff70a
8be4346ca5ae4b568b3e8ce3de9cf46f2e94b416
b0605e848724c5dc478382398b734398abff674c
b0a84ffb7f38f990120c231cfb74956a0ed10d95
1fe517c68df92eb7f379fa87cb0d29d566aad6f4
56bd7edcb5dc878beffb80d4e6a9cfb812378ded
232d87c7dd081d126a079fb45178e0be096cc680
bf1a881715c905c67f7d38dcd5bd6c2afbff1f9b
5b4a6adb5ca24a6cb91cdc55c31506fb278d3a91

and that series should apply cleanly without conflicts to the 3.2 branch. However, it *does* pull in further changes beyond just what's strictly needed to fix this bug - some changes involving detecting whether CPU settings are 'migratable' were sort of mixed up with the changes needed to fix this interaction with qemu, and it's not easily possible to unpick them for backporting.

The update should include both the libvirt build and a qemu build with the workaround removed (so the new code path is followed again). The qemu build may have to be done first, as I *suspect* the workaround will cause libvirt's tests to fail. The workaround was to disable some QMP commands in qemu to force libvirt to use its own code for determining the CPU capabilities, as it used to and still does with qemu < 2.9.0, but libvirt's tests seem to expect qemu 2.9.0 to report those commands when queried as to available QMP commands, so I suspect that test will fail when run against the 'workaround' qemu package.

For extra safety, versioned Conflicts tags could be used to make sure the qemu without the workaround is only installed with a sufficiently new libvirt build...
Comment 1 Laine Stump 2017-07-05 22:32:54 UTC 
> The qemu build may have to be done first, as I *suspect* the workaround will
> cause libvirt's tests to fail.

The tests done by libvirt at build time use results that were previously retrieved from specific versions of qemu (not the qemu that's installed at build time, which could be "none"), so no tests will fail. It should be okay to update the libvirt rpm first - until qemu is updated, libvirt will continue to use the "old" code path. Once qemu is also updated, then libvirt will switch to using the code that is fixed by the above patches.
Comment 2 Adam Williamson 2017-07-05 22:43:26 UTC 
aha, OK. Didn't realize that (I didn't actually check it, I just noticed it in the source). Thanks!
Comment 3 Fedora Update System 2017-07-12 21:02:32 UTC 
libvirt-3.2.1-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ad7e5c5657
Comment 4 Adam Williamson 2017-07-12 21:13:24 UTC 
As I suggested in the original report, it would be best to bundle the libvirt update with a qemu update that disables the qemu workaround. I can do such a qemu build and add it to the update if you like?

The other option would be to just wait until the libvirt update is pushed stable before disabling the qemu workaround, which should be perfectly safe but just take a bit longer...
Comment 5 Cole Robinson 2017-07-12 23:40:46 UTC 
Is there any functional impact for the qemu workaround for the time being?

Part of the problem is that there's other libvirt patches I also want to get out ASAP, so I don't want it to get hung up if the qemu coordination fails for some reason. We can test out the qemu coordination bit separately afterwards. That was my thinking anyways
Comment 6 Adam Williamson 2017-07-13 15:48:52 UTC 
Well, the practical impact would be to any other use of the same qmp functions that we disabled, I guess. But sure, that makes sense. We can just do the qemu update after.
Comment 7 Fedora Update System 2017-07-13 23:51:26 UTC 
libvirt-3.2.1-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ad7e5c5657
Comment 8 Fedora Update System 2017-07-25 16:53:25 UTC 
libvirt-3.2.1-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.