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...
> 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.
aha, OK. Didn't realize that (I didn't actually check it, I just noticed it in the source). Thanks!
libvirt-3.2.1-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ad7e5c5657
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...
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
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.
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
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.