Red Hat Bugzilla – Bug 1468043
Backport "Use more data for comparing CPUs" commit series to work correctly with qemu 2.9.0+
Last modified: 2017-08-03 17:13:00 EDT
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):
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.