Bug 1252363

For more context please see https://bugzilla.redhat.com/show_bug.cgi?id=1251732

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>
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

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/

(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 ;)

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'/>
...

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