Description of problem: When I try to launch a VM, it fails; logs are : anv. 15 17:54:08 mallorne.saclay.inria.fr dbus[938]: [system] Successfully activated service 'org.freedesktop.timedate1' janv. 15 17:54:10 mallorne.saclay.inria.fr libvirtd[2631]: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: rtm, hle janv. 15 17:54:10 mallorne.saclay.inria.fr org.gnome.Boxes[2013]: (gnome-boxes:2615): Boxes-WARNING **: machine.vala:576: Failed to start VM-seven 2: Unable to start domain: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: rtm, hle Version-Release number of selected component (if applicable): libvirt-client-1.2.9.1-2.fc21.x86_64 How reproducible: Try to launch a VM with an Haswell processor Actual results: Fail Expected results: Work Additional info: Seems related to : http://journal.siddhesh.in/posts/buggy-hle-microcode-updates-and-sigills.html http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly
Related discussion on libvirt mailing-list : https://www.redhat.com/archives/libvir-list/2014-December/msg00800.html (and nexts mails)
This is really an example of libvirt working correctly. THe guest config requests a set of CPU features and the host CPU no longer provides them (thanks intel), so the guest won't start. The only real fix here is to edit the guest config to remove use of the features in question.
Or, if it is possible, patch qemu to emulate these features even when the host lacks them.
Daniel Berrange : thanks a lot for the workaround, it's working
*** Bug 1190307 has been marked as a duplicate of this bug. ***
For the record: The same issue hit Fedora 20 after the latest microcode_ctl update, too. Josh Boyer wrote in #1190307: ------------------- As a bit more information, Intel pushed a firmware update that disabled the rtm/hle operations entirely because the TSX support in Haswell is broken in the chip. It works... until it doesn't. Fedora includes that microcode update and it is applied during early boot now. -------------------
> The only real fix here is to edit the guest config to remove use of the features in question. I really doubt that the people that gnome-boxes are targetting are the demographic that would be happy or comfortable with attempting this fix.
For the people wondering what "guest config" people are talking about... Run this command to list domains (aka virtual machines, boxes, etc.): $ virsh list --all Id Name State ---------------------------------------------------- - boxes-unknown shut off If you've used gnome-boxes, it will likely be named something like the above. To edit the config, run this command (using the names from the above command): $ virsh edit boxes-unknown You can then apply the change from bug 1190307, comment 1: <cpu mode="custom" match="exact"> <model fallback="forbid">Haswell</model> <feature policy='disable' name='rtm'/> <feature policy='disable' name='hle'/> </cpu> Add the two lines beginning with <feature within the <cpu></cpu> section. There may be other lines within that section, but I didn't seem to need to change them.
*** Bug 1195061 has been marked as a duplicate of this bug. ***
(In reply to Thomas Jarosch from comment #6) > For the record: The same issue hit Fedora 20 after the latest microcode_ctl > update, too. > > Josh Boyer wrote in #1190307: > ------------------- > As a bit more information, Intel pushed a firmware update that disabled the > rtm/hle operations entirely because the TSX support in Haswell is broken in > the chip. It works... until it doesn't. Fedora includes that microcode > update and it is applied during early boot now. > ------------------- For those like me who were baffled by the fact that rtm and hle flags still show in cpuinfo: apparently the microcode is flashed at every boot; early in the boot process, the cpu still reports these flags.
I had the same issue and found this bug. The upstream libvirt seems to define a new CPU model without TSX, namely Haswell-noTSX. http://libvirt.org/git/?p=libvirt.git;a=commit;h=c563b50605ae9895b981d198e11dbe9f6e18027b Can we backport this to Fedora? Do we need to update the corresponding part in qemu as well?
(In reply to Haruka Iwao from comment #11) > I had the same issue and found this bug. > > The upstream libvirt seems to define a new CPU model without TSX, namely > Haswell-noTSX. > > http://libvirt.org/git/?p=libvirt.git;a=commit; > h=c563b50605ae9895b981d198e11dbe9f6e18027b > > Can we backport this to Fedora? Do we need to update the corresponding part > in qemu as well? I don't know if backporting that patch will actually help any affected users... just give them slightly more accurate mode=host-model behavior, which isn't that big of a deal AFAICT jiri, does that sound right? or will the libvirt patch fix more than that?
I think it is worth backporting, otherwise we'll have never ending stream of bug reports about the "wrong" CPU model listed.
Right, I think we should backport this and commit 53c8062f7eb7028043a314f2f18bf34ff0e82f0d. However, the best user experience will only be achieved when the QEMU commits adding these new CPU models are backported too.
Thanks. virt-install sometimes (depending on its option) creates VM with cpu model='Haswell' not mode='host-model' so this fix would help a lot. I have filed another bug for the qemu as bug 1213053.
libvirt-1.2.9.3-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libvirt-1.2.9.3-1.fc21
Package libvirt-1.2.9.3-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.2.9.3-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7150/libvirt-1.2.9.3-1.fc21 then log in and leave karma (feedback).