|Summary:||Can't launch any VM : rtm and hle CPU features flags needed by libvirt but not in /proc/cpuinfo|
|Product:||[Fedora] Fedora||Reporter:||marianne <marianne>|
|Component:||libvirt||Assignee:||Libvirt Maintainers <libvirt-maint>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||21||CC:||agedosier, berrange, bjrosen, bugzilla-redhat, cfergeau, clalancette, crobinso, eblake, haruka, itamar, jdenemar, jforbes, jmarchan, laine, libvirt-maint, mark, mgrepl, mmilgram, notting, philipp, quantum.analyst, thomas.jarosch, veillard, vincent, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-06-05 23:01:52 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description email@example.com 2015-01-15 16:10:51 UTC
Description of problem: When I try to launch a VM, it fails; logs are : anv. 15 17:54:08 mallorne.saclay.inria.fr dbus: [system] Successfully activated service 'org.freedesktop.timedate1' janv. 15 17:54:10 mallorne.saclay.inria.fr libvirtd: 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: (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-188.8.131.52-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
Comment 1 firstname.lastname@example.org 2015-01-15 16:23:01 UTC
Related discussion on libvirt mailing-list : https://www.redhat.com/archives/libvir-list/2014-December/msg00800.html (and nexts mails)
Comment 2 Daniel Berrangé 2015-01-15 16:25:17 UTC
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.
Comment 3 Eric Blake 2015-01-15 16:28:43 UTC
Or, if it is possible, patch qemu to emulate these features even when the host lacks them.
Comment 4 email@example.com 2015-01-15 16:39:24 UTC
Daniel Berrange : thanks a lot for the workaround, it's working
Comment 5 Ján Tomko 2015-02-10 10:06:51 UTC
*** Bug 1190307 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Jarosch 2015-02-10 16:19:14 UTC
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. -------------------
Comment 7 Elliott Sales de Andrade 2015-02-17 03:29:47 UTC
> 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.
Comment 8 Elliott Sales de Andrade 2015-02-17 03:51:54 UTC
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.
Comment 9 Kashyap Chamarthy 2015-02-23 10:29:30 UTC
*** Bug 1195061 has been marked as a duplicate of this bug. ***
Comment 10 Jerome Marchand 2015-03-04 15:22:10 UTC
(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.
Comment 11 Haruka Iwao 2015-04-17 01:53:13 UTC
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?
Comment 12 Cole Robinson 2015-04-17 12:21:05 UTC
(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?
Comment 13 Daniel Berrangé 2015-04-17 12:23:32 UTC
I think it is worth backporting, otherwise we'll have never ending stream of bug reports about the "wrong" CPU model listed.
Comment 14 Jiri Denemark 2015-04-17 12:32:27 UTC
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.
Comment 15 Haruka Iwao 2015-04-18 08:11:51 UTC
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.
Comment 16 Fedora Update System 2015-04-28 16:55:05 UTC
libvirt-184.108.40.206-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libvirt-220.127.116.11-1.fc21
Comment 17 Fedora Update System 2015-04-29 13:06:13 UTC
Package libvirt-18.104.22.168-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-22.214.171.124-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7150/libvirt-126.96.36.199-1.fc21 then log in and leave karma (feedback).