Bug 1000288 - Libvirt [1.0.5.5-1] guest cannot find Haswell CPU model
Summary: Libvirt [1.0.5.5-1] guest cannot find Haswell CPU model
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 19
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-23 06:17 UTC by Kashyap Chamarthy
Modified: 2013-11-06 14:31 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-06 14:31:53 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Kashyap Chamarthy 2013-08-23 06:17:55 UTC 
Description of the problem:
---------------------------

Libvirt doesn't appear to find the CPU model when a guest is started
with Intel Haswell CPU. This appears to be a regression, as I've been
testing with Haswell CPU model just fine over a few months now. I'm
trying to investigate the root-cause, I'm guessing it's after I updated
QEMU to qemu-2:1.4.2-6.fc19.x86_64.

A similar bug

  https://bugzilla.redhat.com/show_bug.cgi?id=864097 --  Cannot start domains
  with custom CPU model

Version:
--------

  $ rpm -q qemu libvirt-daemon-kvm; uname -r
  qemu-1.4.2-6.fc19.x86_64
  libvirt-daemon-kvm-1.0.5.5-1.fc19.x86_64
  3.11.0-0.rc6.git1.2.fc21.x86_64


How reproducible: Consistently


Steps to reproduce:
-------------------

1. Have the below snippet in the libvirt guest XML:

  $ virsh dumpxml guest-hyp | grep -i custom -A3
    <cpu mode='custom' match='exact'>
      <model fallback='allow'>Haswell</model>
      <feature policy='require' name='vmx'/>
    </cpu>

2. Start the guest

  $ virsh start guest-hyp


Actual results: 
---------------

  $ virsh start guest-hyp
  error: Failed to start domain guest-hyp
  error: internal error Cannot find suitable CPU model for given data


Expected results:
-----------------

Guest starts successfully with custom CPU model (Haswell).


Additional info:
----------------

Machine info:

  $ virsh  capabilities | virsh cpu-baseline /dev/stdin 
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Haswell</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='abm'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='rdrand'/>
    <feature policy='require' name='f16c'/>
    <feature policy='require' name='osxsave'/>
    <feature policy='require' name='pdcm'/>
    <feature policy='require' name='xtpr'/>
    <feature policy='require' name='tm2'/>
    <feature policy='require' name='est'/>
    <feature policy='require' name='smx'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='ds_cpl'/>
    <feature policy='require' name='monitor'/>
    <feature policy='require' name='dtes64'/>
    <feature policy='require' name='pbe'/>
    <feature policy='require' name='tm'/>
    <feature policy='require' name='ht'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='acpi'/>
    <feature policy='require' name='ds'/>
    <feature policy='require' name='vme'/>
  </cpu>


Capture debug logging:

Enable debug log levels in /etc/libvirt/libvirtd.conf

  log_level = 1
  log_outputs = "1:file:/var/tmp/libvirtd.log"

Restart libvirtd

  $ systemctl restart libvirtd

Start the guest and capture the log fragment.


Intel Haswell CPU model addtion to libvirt patch:

  https://www.redhat.com/archives/libvir-list/2012-November/msg00987.html
Comment 1 Kashyap Chamarthy 2013-08-23 06:20:04 UTC 
libvirt debug log info:

  $ /var/tmp/libvirtd.log
  [...]
  2013-08-23 05:22:43.984+0000: 1182: debug : cpuHasFeature:431 : arch=x86_64, data=0x7fcf001a4750, feature=svm
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:141 : cpu=0x7fcf001114a0, data=0x7fcf001a4750, nmodels=24, preferred=Haswell
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[0]=qemu64  QEMU Virtual CPU version 1.4.2                  
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[1]=phenom  AMD Phenom(tm) 9550 Quad-Core Processor         
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[2]=core2duo  Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz 
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[3]=kvm64  Common KVM processor                            
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[4]=qemu32  QEMU Virtual CPU version 1.4.2                  
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[5]=kvm32  Common 32-bit KVM processor                     
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[6]=coreduo  Genuine Intel(R) CPU           T2600  @ 2.16GHz 
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[7]=486                                                  
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[8]=pentium                                                  
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[9]=pentium2                                                  
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[10]=pentium3                                                  
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[11]=athlon  QEMU Virtual CPU version 1.4.2                  
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[12]=n270  Intel(R) Atom(TM) CPU N270   @ 1.60GHz          
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[13]=Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)   
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[14]=Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)    
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[15]=Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)       
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[16]=Westmere  Westmere E56xx/L56xx/X56xx (Nehalem-C)          
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[17]=SandyBridge  Intel Xeon E312xx (Sandy Bridge)                
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[18]=Haswell  Intel Core Processor (Haswell)                  
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[19]=Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)           
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[20]=Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)          
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[21]=Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)          
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[22]=Opteron_G4  AMD Opteron 62xx class CPU                      
  2013-08-23 05:22:43.988+0000: 1182: debug : cpuDecode:145 : models[23]=Opteron_G5  AMD Opteron 63xx class CPU                      
  2013-08-23 05:22:43.990+0000: 1182: debug : x86Decode:1334 : CPU model Opteron_G5 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.990+0000: 1182: debug : x86Decode:1334 : CPU model Opteron_G4 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.990+0000: 1182: debug : x86Decode:1334 : CPU model Opteron_G3 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.990+0000: 1182: debug : x86Decode:1334 : CPU model Opteron_G2 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.990+0000: 1182: debug : x86Decode:1334 : CPU model Opteron_G1 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.990+0000: 1182: debug : x86Decode:1334 : CPU model phenom not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model athlon not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: warning : x86Decode:1330 : Preferred CPU model Haswell not allowed by hypervisor; closest supported model will be used
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model SandyBridge not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model Westmere not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model Nehalem not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model Penryn not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model Conroe not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model qemu64 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model kvm64 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model cpu64-rhel6 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model cpu64-rhel5 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model kvm32 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model qemu32 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model core2duo not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model n270 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model coreduo not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model pentiumpro not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model pentium3 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model pentium2 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model pentium not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: debug : x86Decode:1334 : CPU model 486 not allowed by hypervisor; ignoring
  2013-08-23 05:22:43.991+0000: 1182: error : x86Decode:1383 : internal error Cannot find suitable CPU model for given data
  2013-08-23 05:22:43.991+0000: 1182: debug : cpuDataFree:212 : arch=x86_64, data=0x7fcf001a4750
  2013-08-23 05:22:43.991+0000: 1182: debug : virObjectUnref:258 : OBJECT_UNREF: obj=0x7fcf000c9a60
  2013-08-23 05:22:43.991+0000: 1182: debug : virObjectUnref:258 : OBJECT_UNREF: obj=0x7fcf0006d5b0
  2013-08-23 05:22:43.991+0000: 1182: debug : virFileClose:72 : Closed fd 22
  2013-08-23 05:18:24.705+0000: 1182: debug : virObjectRef:295 : OBJECT_REF: obj=0x7fcf0006d5b0
  2013-08-23 05:18:24.705+0000: 1182: debug : qemuProcessStop:3992 : Shutting down VM 'guest-hyp' pid=-1 flags=2
  2013-08-23 05:18:24.705+0000: 1182: debug : virNetServerRemoveShutdownInhibition:815 : srv=0x7fcf212601a0 inhibitions=0
  2013-08-23 05:18:24.705+0000: 1182: debug : virObjectRef:295 : OBJECT_REF: obj=0x7fcf0006d5b0
  2013-08-23 05:18:24.705+0000: 1182: debug : virObjectUnref:258 : OBJECT_UNREF: obj=0x7fcf0006d5b0
  2013-08-23 05:18:24.705+0000: 1182: debug : virFileClose:72 : Closed fd 22
  [...]
Comment 2 Jiri Denemark 2013-08-26 12:32:58 UTC 
(In reply to Kashyap Chamarthy from comment #0)
> Description of the problem:
> ---------------------------
> 
> Libvirt doesn't appear to find the CPU model when a guest is started
> with Intel Haswell CPU. This appears to be a regression, as I've been
> testing with Haswell CPU model just fine over a few months now. I'm
> trying to investigate the root-cause, I'm guessing it's after I updated
> QEMU to qemu-2:1.4.2-6.fc19.x86_64.

Yes, that's very likely. What was the qemu version you used before the update? The problem is that libvirt does not know how to correctly parse CPU models supported by the upgraded qemu.
Comment 3 Kashyap Chamarthy 2013-08-26 17:31:43 UTC 
(In reply to Jiri Denemark from comment #2)
> (In reply to Kashyap Chamarthy from comment #0)
> > Description of the problem:
> > ---------------------------
> > 
> > Libvirt doesn't appear to find the CPU model when a guest is started
> > with Intel Haswell CPU. This appears to be a regression, as I've been
> > testing with Haswell CPU model just fine over a few months now. I'm
> > trying to investigate the root-cause, I'm guessing it's after I updated
> > QEMU to qemu-2:1.4.2-6.fc19.x86_64.
> 
> Yes, that's very likely. What was the qemu version you used before the
> update?

qemu-2:1.4.2-5.fc19.x86_64

> The problem is that libvirt does not know how to correctly parse CPU
> models supported by the upgraded qemu.

Should this 'problem' be tracked in a separate bug?
Comment 4 Jiri Denemark 2013-08-29 19:11:30 UTC 
This is all pretty strange. The "problem" is not in fact a bug. It was caused by a change to QEMU's -cpu help output, but the change happened after libvirt started to use QMP probing rather then invoking QEMU with different command line options and parsing its output. That is new enough libvirt is not able to correctly parse the -cpu help output of new QEMU. So it seems QMP probing doesn't work with qemu-2:1.4.2-6.fc19 and libvirt is forced to use the old probing method which is doomed to fail. Unfortunately, I don't have the setup to test this myself... could you restart libvirtd and run virsh capabilities with each of the qemu packages and attach libvirt's debug logs generated in both cases?
Comment 5 Cole Robinson 2013-11-06 14:31:53 UTC 
No response for a while, so closing. Kashyap, if this is still affecting you, please reopen with the info requested in Comment #4
Note You need to log in before you can comment on or make changes to this bug.