Bug 1252363 - internal error: Cannot find suitable CPU model for given data
internal error: Cannot find suitable CPU model for given data
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.1
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Jiri Denemark
Virtualization Bugs
:
Depends On:
Blocks: 1251732
  Show dependency treegraph
 
Reported: 2015-08-11 05:08 EDT by Francesco Romani
Modified: 2015-11-19 01:50 EST (History)
17 users (show)

See Also:
Fixed In Version: libvirt-1.2.17-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1160318
Environment:
Last Closed: 2015-11-19 01:50:45 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Francesco Romani 2015-08-11 05:08:11 EDT
We hit that while testing oVirt 3.6.0 on RHEL 7.1.

Relevant package versions:

[root@vega08 ~]# rpm -qa | grep libvirt
libvirt-daemon-driver-interface-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-qemu-1.2.8-16.el7_1.3.x86_64
libvirt-python-1.2.8-7.el7_1.1.x86_64
libvirt-daemon-driver-lxc-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-storage-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-1.2.8-16.el7_1.3.x86_64
libvirt-lock-sanlock-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-secret-1.2.8-16.el7_1.3.x86_64
libvirt-1.2.8-16.el7_1.3.x86_64
libvirt-client-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-config-nwfilter-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-config-network-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-kvm-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-nodedev-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-network-1.2.8-16.el7_1.3.x86_64
libvirt-daemon-driver-nwfilter-1.2.8-16.el7_1.3.x86_64

[root@vega08 ~]# rpm -qa | grep qemu
libvirt-daemon-driver-qemu-1.2.8-16.el7_1.3.x86_64
ipxe-roms-qemu-20130517-6.gitc4bce43.el7.noarch
qemu-kvm-ev-2.1.2-23.el7_1.4.1.x86_64
qemu-kvm-common-ev-2.1.2-23.el7_1.4.1.x86_64
qemu-img-ev-2.1.2-23.el7_1.4.1.x86_64
qemu-kvm-tools-ev-2.1.2-23.el7_1.4.1.x86_64


+++ This bug was initially created as a clone of Bug #1160318 +++

Description of problem:

After installing Fedora 21 Workstation Alpha on Lenovo Thinkpad T410. virt-manager is not able to create any VM. 

Version-Release number of selected component (if applicable):
qemu-kvm-2.1.2-6.fc21.x86_64
libvirt-daemon-1.2.9-4.fc21.x86_64
virt-manager-1.1.0-3.git310f6527.fc21.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 21 Alpha on T410
2. Try to create VM on virt-manager
3. Get to the end of the wizard

Actual results:
It fails with error "internal error: Cannot find suitable CPU model for given data"

Expected results:
It should create the VM.

Additional info:
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1854, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 411, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 475, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3361, in
createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: internal error: Cannot find suitable CPU model for given data

On "systemctl status libvirtd" I can see:

Nov 04 10:23:41 lappie.mkeder.com libvirtd[3822]: Preferred CPU model
Westmere not allowed by hypervisor; closest supported model will be
used
Nov 04 10:23:41 lappie.mkeder.com libvirtd[3822]: internal error:
Cannot find suitable CPU model for given data

I haven't tried Fedora 20 on it but I might re-install it soon. Just
wanted to give my feedback for Fedora 21.
Doing a google search it seems that some people had the same problem a
few months ago and they solved but by updating. Seems to be some sort
of problem between libvirt and qemu-kvm. Like this:

https://www.redhat.com/archives/libvir-list/2014-March/msg00609.html


Logs are on fpaste:

virsh capabilities -> http://paste.fedoraproject.org/147736/15110815/
libvirtd debug -> http://fpaste.org/147741/51114361/

--- Additional comment from Matías Kreder on 2014-11-04 09:46:49 EST ---

This was fixed by stopping libvirt, removing all files on /var/cache/libvirt/qemu/capabilities/ and starting it again.

After the installation on Fedora 21 Alpha, when trying to create the VM the first time the BIOS setting for Intel Virtualization was disabled. After I enabled it I was getting the error reported on this bug. It was fixed by removing the cached files. 

It will be good if the cache files are cleaned up on this error or something so this doesn't happen to an average user.

--- Additional comment from Matías Kreder on 2014-11-04 10:00:30 EST ---

libvirtd log with intel-vt disabled

--- Additional comment from Matías Kreder on 2014-11-04 10:10:12 EST ---



--- Additional comment from Jiri Denemark on 2014-11-12 11:08:40 EST ---

So the problem is in the /usr/bin/qemu-kvm wrapper, which runs qemu-system-x86_64 with -machine accel=kvm to force KVM. When libvirt starts, it probes QEMU binaries by running them with "-S -no-user-config -nodefaults -nographic -M none -qmp ... -pidfile ... -daemonize" to get a dummy process with QMP monitor which we can ask for available QMP commands, machine types, and lots of other things. Howver, when qemu-kvm wrapper forces the dummy process to enable KVM, it fails to start if KVM cannot be enabled for some reason (missing module, disabled by BIOS, ...). If that happens, we fall back to the old way of parsing -help, -cpu ?, etc. output. And since we implemented QMP probing for QEMU 1.2.0, we don't keep up with any changes made in "-cpu ?" output and thus fail to parse it properly. But we shouldn't even try to use the old way of probing QEMU capabilities because we know it's not going to work...

--- Additional comment from Jiri Denemark on 2014-11-12 11:10:03 EST ---

Patch sent upstream for review: https://www.redhat.com/archives/libvir-list/2014-November/msg00407.html

--- Additional comment from Cole Robinson on 2014-11-12 11:15:25 EST ---

Another option could be to alter the qemu-kvm wrapper script and change it to not use accel=kvm if -nodefaults is passed, that way we don't need to work around it in libvirt

--- Additional comment from Cole Robinson on 2014-11-12 11:16:28 EST ---

(Although that patch looks useful anyways)

--- Additional comment from Eduardo Habkost on 2014-11-12 11:24:14 EST ---

Can't the qemu-kvm wrapper simply use accel=kvm:tcg, and fallback to TCG if KVM is not available? (Wasn't it the behavior of qemu-kvm in the past, before the upstream merge?)

--- Additional comment from Jiri Denemark on 2014-11-13 18:23:52 EST ---

Pushed upstream as v1.2.10-104-gae3e29e6:

commit ae3e29e6e7a9a208732f22721e735d238b2aa8cb
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Wed Nov 12 16:49:59 2014 +0100

    qemu: Don't try to parse -help for new QEMU
    
    Since QEMU 1.2.0, we switched to QMP probing instead of parsing -help
    (and other commands, such as -cpu ?) output. However, if QMP probing
    failed, we still tried starting QEMU with various options and parsing
    the output, which was guaranteed to fail because the output changed.
    Let's just refuse parsing -help for QEMU >= 1.2.0.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1160318
    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

--- Additional comment from Fedora Update System on 2014-11-15 20:23:23 EST ---

libvirt-1.2.9.1-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/libvirt-1.2.9.1-1.fc21

--- Additional comment from Fedora Update System on 2014-11-16 09:41:50 EST ---

Package libvirt-1.2.9.1-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.1-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15167/libvirt-1.2.9.1-1.fc21
then log in and leave karma (feedback).

--- Additional comment from Fedora Update System on 2014-11-18 07:20:31 EST ---

libvirt-1.2.9.1-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 1 Francesco Romani 2015-08-11 05:08:58 EDT
For more context please see https://bugzilla.redhat.com/show_bug.cgi?id=1251732
Comment 4 Luyao Huang 2015-09-11 00:03:08 EDT
Hi Jirika,

I cannot reproduce this issue with qemu-kvm-rhev-2.1.2-23.el7_1.4.x86_64, libvirt-1.2.8-16.el7_1.3.x86_64, and libvirt will create a right capabilities file even i disable the kvm in BIOS and remove the kvm mode via rmmod. qemu will back to tcg (this was mentioned by Eduardo in bug 1160318 comment 8):

# /usr/libexec/qemu-kvm -S -no-user-config -nodefaults -nographic -M none -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.


But i found there is another way (i guess this bug and bug 1195882 maybe hit this issue) to reproduce this issue:

It was first mentioned in this mail:
http://www.redhat.com/archives/libvir-list/2014-October/msg00075.html

and fixed by this commit:

commit 0ed1b55b20300e0ea53925349d918935c2114bf2
Author: Martin Kletzander <mkletzan@redhat.com>
Date:   Thu Oct 9 08:18:33 2014 +0200

    qemu: make sure capability probing process can start


the way to reproduce it in libvirt-1.2.8-16.el7_1.3.x86_64:

1. first start a qemu process:

# /usr/libexec/qemu-kvm -S -no-user-config -nodefaults -nographic -M none -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile /var/lib/libvirt/qemu/capabilities.pidfile -daemonize
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
Back to tcg accelerator.

2. remove the capabilities and restart libvirtd:

# rm -f /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml

# service libvirtd restart
Redirecting to /bin/systemctl restart  libvirtd.service

3. check the capabilities:
# vim /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml
...
  <version>2001002</version>
  <kvmVersion>0</kvmVersion>
  <arch>x86_64</arch>
  <cpu name='qemu64  QEMU Virtual CPU version 2.1.2                  '/>
  <cpu name='phenom  AMD Phenom(tm) 9550 Quad-Core Processor         '/>
  <cpu name='core2duo  Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz '/>
  <cpu name='kvm64  Common KVM processor                            '/>
  <cpu name='qemu32  QEMU Virtual CPU version 2.1.2                  '/>
  <cpu name='kvm32  Common 32-bit KVM processor                     '/>
  <cpu name='coreduo  Genuine Intel(R) CPU           T2600  @ 2.16GHz '/>
  <cpu name='486                                                  '/>
  <cpu name='pentium                                                  '/>
  <cpu name='pentium2                                                  '/>
  <cpu name='pentium3                                                  '/>
  <cpu name='athlon  QEMU Virtual CPU version 2.1.2                  '/>
  <cpu name='n270  Intel(R) Atom(TM) CPU N270   @ 1.60GHz          '/>
  <cpu name='cpu64-rhel6  QEMU Virtual CPU version (cpu64-rhel6)          '/>
  <cpu name='Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)   '/>
  <cpu name='Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)    '/>
  <cpu name='Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)       '/>
  <cpu name='Westmere  Westmere E56xx/L56xx/X56xx (Nehalem-C)          '/>
  <cpu name='SandyBridge  Intel Xeon E312xx (Sandy Bridge)                '/>
  <cpu name='Haswell  Intel Core Processor (Haswell)                  '/>
  <cpu name='Broadwell  Intel Core Processor (Broadwell)                '/>
  <cpu name='Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)           '/>
  <cpu name='Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)          '/>
  <cpu name='Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)          '/>
  <cpu name='Opteron_G4  AMD Opteron 62xx class CPU                      '/>
  <cpu name='Opteron_G5  AMD Opteron 63xx class CPU                      '/>
...


4. try to start a guest 

# virsh dumpxml test3
...
  <cpu mode='host-model'>
    <model fallback='allow'/>
  </cpu>
...

# virsh start test3
error: Failed to start domain test3
error: internal error: Cannot find suitable CPU model for given data


Would you please help to check out if i can use this way to reproduce this bug and verify this bug ?

Thanks in advance for your reply.

Luyao
Comment 5 Jiri Denemark 2015-09-11 09:35:25 EDT
Yeah, this is a valid way of reproducing the bug. The important thing is QMP probing has to fail for this bug to reproduce and the reason for the failure is irrelevant.

s/Jirika/Jirka/
Comment 6 Luyao Huang 2015-09-13 22:49:26 EDT
(In reply to Jiri Denemark from comment #5)
> Yeah, this is a valid way of reproducing the bug. The important thing is QMP
> probing has to fail for this bug to reproduce and the reason for the failure
> is irrelevant.
> 

Got it, and since commit 0ed1b55 should already be contained in the latest version and i will use another way to reproduce and verify this issue.

> s/Jirika/Jirka/

Okay, thanks for pointing out that, i will take notes this time ;)
Comment 7 Luyao Huang 2015-09-13 23:12:09 EDT
I can reproduce this issue with libvirt-1.2.8-16.el7_1.3.x86_64 and qemu-kvm-rhev-2.1.2-23.el7_1.4.x86_64:

1. rename qemu-kvm to qemu-kvm-bak:

# mv /usr/libexec/qemu-kvm /usr/libexec/qemu-kvm-bak

2. prepare a shell script in /usr/libexec/qemu-kvm (to make libvirt fail to detect the capabilities via QMP):

# cat /usr/libexec/qemu-kvm
#!/bin/bash
for i in "$@"
do
    if [[ "/var/lib/libvirt/qemu/capabilities.pidfile" == "$i" ]]
    then
        exit 1
    fi
done

exec /usr/libexec/qemu-kvm-bak "$@"

3. stop the libvirtd and remove all capabilities:

# service libvirtd stop
Redirecting to /bin/systemctl stop  libvirtd.service

# rm -f /var/cache/libvirt/qemu/capabilities/*

4. start libvirtd and check capabilities file:

# service libvirtd start
Redirecting to /bin/systemctl start  libvirtd.service


# cat /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml
...
  <version>2001002</version>
  <kvmVersion>0</kvmVersion>
  <arch>x86_64</arch>
  <cpu name='qemu64  QEMU Virtual CPU version 2.1.2                  '/>
  <cpu name='phenom  AMD Phenom(tm) 9550 Quad-Core Processor         '/>
  <cpu name='core2duo  Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz '/>
  <cpu name='kvm64  Common KVM processor                            '/>
  <cpu name='qemu32  QEMU Virtual CPU version 2.1.2                  '/>
  <cpu name='kvm32  Common 32-bit KVM processor                     '/>
  <cpu name='coreduo  Genuine Intel(R) CPU           T2600  @ 2.16GHz '/>
  <cpu name='486                                                  '/>
  <cpu name='pentium                                                  '/>
  <cpu name='pentium2                                                  '/>
  <cpu name='pentium3                                                  '/>
  <cpu name='athlon  QEMU Virtual CPU version 2.1.2                  '/>
  <cpu name='n270  Intel(R) Atom(TM) CPU N270   @ 1.60GHz          '/>
  <cpu name='cpu64-rhel6  QEMU Virtual CPU version (cpu64-rhel6)          '/>
  <cpu name='Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)   '/>
  <cpu name='Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)    '/>
  <cpu name='Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)       '/>
  <cpu name='Westmere  Westmere E56xx/L56xx/X56xx (Nehalem-C)          '/>
  <cpu name='SandyBridge  Intel Xeon E312xx (Sandy Bridge)                '/>
  <cpu name='Haswell  Intel Core Processor (Haswell)                  '/>
  <cpu name='Broadwell  Intel Core Processor (Broadwell)                '/>
  <cpu name='Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)           '/>
  <cpu name='Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)          '/>
  <cpu name='Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)          '/>
  <cpu name='Opteron_G4  AMD Opteron 62xx class CPU                      '/>
  <cpu name='Opteron_G5  AMD Opteron 63xx class CPU                      '/>
  <cpu name='host  KVM processor with all supported host features (only available in KVM mode)'/>
...

5. try to start a guest:

# virsh start test3
error: Failed to start domain test3
error: internal error: Cannot find suitable CPU model for given data

And verify this issue (which libvirt shouldn't try use -help cmd line to create wrong capabilities) with libvirt-1.2.17-8.el7.x86_64:

1. update libvirt from an version which have already created a wrong capabilities:

# cat /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml
...


# yum  update /mnt/rhel7/libvirt/1.2.17-8.el7/libvirt-*

2. check the capabilities:

# ll /var/cache/libvirt/qemu/capabilities/
total 0

3. and i can find some log like this in libvirtd.log:

2015-09-14 03:00:42.596+0000: 18356: error : virQEMUCapsParseHelpStr:1442 : unsupported configuration: QEMU 2.1.2 is too new for help parsing
2015-09-14 03:00:42.597+0000: 18356: warning : virQEMUCapsLogProbeFailure:3537 : Failed to probe capabilities for /usr/libexec/qemu-kvm: unsupported configuration: QEMU 2.1.2 is too new for help parsing
2015-09-14 03:00:42.717+0000: 18356: error : virQEMUCapsParseHelpStr:1442 : unsupported configuration: QEMU 2.1.2 is too new for help parsing
2015-09-14 03:00:42.717+0000: 18356: warning : virQEMUCapsLogProbeFailure:3537 : Failed to probe capabilities for /usr/libexec/qemu-kvm: unsupported configuration: QEMU 2.1.2 is too new for help parsing

4. try to start a guest:

# virsh start test3
error: Failed to start domain test3
error: invalid argument: could not find capabilities for arch=x86_64 

5. clean up the script:

# mv /usr/libexec/qemu-kvm /usr/libexec/testkvm
# mv /usr/libexec/qemu-kvm-bak /usr/libexec/qemu-kvm

6. guest can start success (no need restart libvirtd):

# virsh start test3
Domain test3 started

7. and this time libvirt will create a right capabilities file:

# cat /var/cache/libvirt/qemu/capabilities/3c76bc41d59c0c7314b1ae8e63f4f765d2cf16abaeea081b3ca1f5d8732f7bb1.xml
...
  <version>2001002</version>
  <kvmVersion>0</kvmVersion>
  <package> (qemu-kvm-rhev-2.1.2-23.el7_1.4)</package>
  <arch>x86_64</arch>
  <cpu name='Opteron_G5'/>
  <cpu name='Opteron_G4'/>
  <cpu name='Opteron_G3'/>
  <cpu name='Opteron_G2'/>
  <cpu name='Opteron_G1'/>
  <cpu name='Broadwell'/>
  <cpu name='Haswell'/>
  <cpu name='SandyBridge'/>
  <cpu name='Westmere'/>
  <cpu name='Nehalem'/>
  <cpu name='Penryn'/>
  <cpu name='Conroe'/>
  <cpu name='cpu64-rhel6'/>
  <cpu name='n270'/>
  <cpu name='athlon'/>
  <cpu name='pentium3'/>
  <cpu name='pentium2'/>
  <cpu name='pentium'/>
  <cpu name='486'/>
  <cpu name='coreduo'/>
  <cpu name='kvm32'/>
  <cpu name='qemu32'/>
  <cpu name='kvm64'/>
  <cpu name='core2duo'/>
  <cpu name='phenom'/>
  <cpu name='qemu64'/>
...
Comment 9 errata-xmlrpc 2015-11-19 01:50:45 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html

Note You need to log in before you can comment on or make changes to this bug.