Bug 864097 - Cannot start domains with custom CPU model
Cannot start domains with custom CPU model
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.4
All Linux
low Severity medium
: rc
: ---
Assigned To: Jiri Denemark
Virtualization Bugs
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-08 11:04 EDT by Jiri Denemark
Modified: 2013-02-21 02:25 EST (History)
7 users (show)

See Also:
Fixed In Version: libvirt-0.10.2-3.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 02:25:48 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jiri Denemark 2012-10-08 11:04:04 EDT
Description of problem:

Starting a domain with custom CPU model fails with "Cannot find suitable CPU
model for given data".

Version-Release number of selected component (if applicable):

libvirt-0.10.2-1.el6.x86_64
qemu-kvm-0.12.1.2-2.320.el6.x86_64

How reproducible:

100%

Steps to Reproduce:
1. configure a domain with, e.g.,
    <cpu mode='custom' match='exact'>
      <model fallback='allow'>Penryn</model>
    </cpu>
2. virsh start the domain


Actual results:

error: Failed to start domain fedora1
error: internal error Cannot find suitable CPU model for given data

libvirtd debug logs show the following mess:

2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:141 : cpu=0x7f7460007130, data=0x7f746000a340, nmodels=24, preferred=Penryn
2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:145 : models[0]=Opteron_G4  AMD Opteron 62xx class CPU                      
2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:145 : models[1]=Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)          
2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:145 : models[2]=Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)          
2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:145 : models[3]=Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)           
2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:145 : models[4]=SandyBridge  Intel Xeon E312xx (Sandy Bridge)                
2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:145 : models[5]=Westmere  Westmere E56xx/L56xx/X56xx (Nehalem-C)          
2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:145 : models[6]=Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)       
2012-10-08 14:32:24.489+0000: 2566: debug : cpuDecode:145 : models[7]=Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)    
...

Expected results:

No error. Models in libvirtd debug logs should not contain their description.

Additional info:

Patch sent upstream for review:

https://www.redhat.com/archives/libvir-list/2012-October/msg00251.html
Comment 2 hongming 2012-10-08 23:54:47 EDT
Hi Jiri 

I can't reproduce it in the same libvirt -0.10.2-1.el6.x86_64. The domain can be successfully started. Does it need some other configurations ? And the libvirtd debug log issue can be reproduced. 


Steps

# rpm -q libvirt qemu-kvm
libvirt-0.10.2-1.el6.x86_64
qemu-kvm-0.12.1.2-2.310.el6.x86_64


# virsh start rhel6.2
Domain rhel6.2 started

# virsh dumpxml rhel6.2
<domain type='kvm' id='6'>
 .....
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Penryn</model>
  </cpu>
 ......
</domain>

# vim /var/log/libvirtd.log

2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:141 : cpu=0x7f664c133220, data=0x7f664c1a1830, nmodels=23, preferred=Penryn
2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:145 : models[0]=Opteron_G4
2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:145 : models[1]=Opteron_G3
2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:145 : models[2]=Opteron_G2
2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:145 : models[3]=Opteron_G1
2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:145 : models[4]=SandyBridge
2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:145 : models[5]=Westmere
2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:145 : models[6]=Nehalem
2012-10-09 03:45:51.172+0000: 2472: debug : cpuDecode:145 : models[7]=Penryn
Comment 3 Jiri Denemark 2012-10-10 07:49:52 EDT
It's important to use new enough qemu since it changed the output of -cpu ?. As mentioned in bug description, I used qemu-kvm-0.12.1.2-2.320.el6.x86_64 and anything newer will work too.
Comment 4 Jiri Denemark 2012-10-12 09:48:17 EDT
The patch was considered unsuitable for upstream since it touches code that will never be used with new versions of QEMU that changed the output.

Sent as RHEL-only patch for review: http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-October/msg00614.html
Comment 8 hongming 2012-10-16 04:24:33 EDT
Verify it as follows. The result is expected.So move its status to VERIFIED.

1.# rpm -q libvirt qemu-kvm
libvirt-0.10.2-3.el6.x86_64
qemu-kvm-0.12.1.2-2.322.el6.x86_64


2.configure a domain with, e.g.,
    <cpu mode='custom' match='exact'>
      <model fallback='allow'>Penryn</model>
    </cpu>


3.# virsh start rhel6.3-new
Domain rhel6.3-new started


4.Check libvirtd debug log.

2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:141 : cpu=0x7f696403ad70, data=0x7f6964039150, nmodels=24, preferred=Penryn
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[0]=Opteron_G4
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[1]=Opteron_G3
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[2]=Opteron_G2
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[3]=Opteron_G1
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[4]=SandyBridge
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[5]=Westmere
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[6]=Nehalem
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[7]=Penryn
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[8]=Conroe
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[9]=cpu64-rhel5
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[10]=cpu64-rhel6
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[11]=n270
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[12]=athlon
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[13]=pentium3
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[14]=pentium2
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[15]=pentium
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[16]=486
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[17]=coreduo
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[18]=qemu32
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[19]=kvm64
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[20]=core2duo
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[21]=phenom
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[22]=qemu64
2012-10-16 07:40:20.697+0000: 13511: debug : cpuDecode:145 : models[23]=host
Comment 9 errata-xmlrpc 2013-02-21 02:25:48 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.

http://rhn.redhat.com/errata/RHSA-2013-0276.html

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