Red Hat Bugzilla – Bug 707524
virt-what not detecting kvm guests because cpu model does not contain 'QEMU' string
Last modified: 2011-12-20 07:32:44 EST
+++ This bug was initially created as a clone of Bug #647862 +++ Description of problem: virt-what is silent inside a 32-bit guest run on top of Fedora 13 64-bit kvm Version-Release number of selected component (if applicable): hypervisor: qemu-kvm-0.12.5-1.fc13.x86_64 VM: How reproducible: Steps to Reproduce: 1. running 64-bit F13 host 2. start 32-bit F13 VM 3. virt-what 4. /usr/libexec/virt-what-cpuid-helper 5. cat /proc/cpuinfo Actual results: $ virt-what $ /usr/libexec/virt-what-cpuid-helper KVMKVMKVM $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Pentium II (Klamath) stepping : 3 cpu MHz : 2792.776 cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic pge cmov mmx fxsr sse sse2 up pni hypervisor bogomips : 5585.55 clflush size : 32 cache_alignment : 32 address sizes : 36 bits physical, 32 bits virtual power management: Expected results: virt-what should output kvm and/or qemu Additional info: Let me know if you need any more details about the XML that libvirt uses to describe my VM, or any other tests I can help run. --- Additional comment from eblake@redhat.com on 2010-10-29 14:09:53 EDT --- VM: virt-what-1.3-3.fc13.i686 --- Additional comment from rjones@redhat.com on 2010-10-29 15:09:21 EDT --- Eric, are you running virt-what as root? Do you have a /proc/xen directory in the guest? (Not exactly sure why it would be there, but please check). What is the output of dmidecode? I happen to have a F13 32 bit guest on top of F14 x86_64 host, which is very nearly the same as you describe. # virt-what kvm # /usr/libexec/virt-what-cpuid-helper KVMKVMKVM So it works for me. --- Additional comment from rjones@redhat.com on 2010-10-29 15:10:29 EDT --- Ah, hang about ... I see what's happening, and it's a bug. I assume that you are passing the -cpu flag to qemu (or maybe via libvirt)? --- Additional comment from eblake@redhat.com on 2010-10-29 15:33:35 EDT --- libvirt is probably passing the -cpu flag. Let me check... LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.11 -cpu qemu32 -enable-kvm -m 768 -smp 1,sockets=1,cores=1,threads=1 -name fedora_13-initial -uuid 24ab99db-bf50-085d-d3e5-7528243ae9b0 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/fedora_13-initial.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/fedora_13-clone.img,if=none,id=drive-virtio-disk0,boot=on,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:65:82:9e,bus=pci.0,addr=0x5 -net tap,fd=48,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -k en-us -vga cirrus -device ES1370,id=sound0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 char device redirected to /dev/pts/4 Yep - -cpu qemu32. --- Additional comment from rjones@redhat.com on 2010-10-29 16:08:12 EDT --- Created attachment 456553 [details] Patch to ignore /proc/cpuinfo in QEMU/KVM test Suggested patch. --- Additional comment from eblake@redhat.com on 2010-10-29 16:16:22 EDT --- Patch works for my testing of kvm guests. --- Additional comment from rjones@redhat.com on 2010-10-30 02:20:50 EDT --- Comment on attachment 456553 [details] Patch to ignore /proc/cpuinfo in QEMU/KVM test This patch is wrong. Baremetal would appear as "qemu". We need to test dmidecode output as well. --- Additional comment from rjones@redhat.com on 2011-05-24 13:36:54 EDT --- Bump this up to Rawhide, not fixed upstream. --- Additional comment from pbonzini@redhat.com on 2011-05-25 04:28:31 EDT --- dmidecode output can be changed as well. It seems better to provide custom CPUID leaves (like KVMKVMKVM) in non-kvm QEMU, and in the meanwhile use /proc/cpuinfo to detect non-kvm QEMU. --- Additional comment from rjones@redhat.com on 2011-05-25 05:34:36 EDT --- *** Bug 707352 has been marked as a duplicate of this bug. *** --- Additional comment from rjones@redhat.com on 2011-05-25 05:44:04 EDT --- A simple reproducer for this is to edit the libvirt configuration for a guest, adding an explicit CPU model. eg for a 64 bit guest you could add: <domain> <!-- ... --> <cpu match='exact'> <model>core2duo</model> <vendor>Intel</vendor> </cpu> The effect of this is to add the following flag to the qemu command line: -cpu core2duo When the guest has been booted, you will see inside the guest, in /proc/cpuinfo: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz [etc] Note that the "QEMU" string is no longer present in /proc/cpuinfo. virt-what now fails to detect that this is QEMU, producing no output. I'll just make a simple patch for this. Paolo in comment 9 is correct that a general fix is going to involve fixing qemu (wish me luck with that), but we can work around this easily by detecting the strings in dmidecode for now. --- Additional comment from rjones@redhat.com on 2011-05-25 06:17:44 EDT --- I pushed the following patch upstream which fixes the problem for me: http://git.annexia.org/?p=virt-what.git;a=commitdiff;h=441ce9d9ecf9edf0f325c280451ba69dc160882e Tested on KVM with explicit -cpu core2duo option as described in the previous comment. However it won't work for (non-accelerated) qemu with the explicit -cpu option, although that should be a rare case.
By the way, I have not verified that this bug happens in RHEL 6.1. This bug is just a placeholder.
Should be automatically fixed because of the rebase (bug 672211).
Start the guest by the command: qemu-kvm -cpu core2duo rhel6.img then install virt-what and run it in the guest. Reproduced on virt-what-1.3-4.4: virt-what outputs nothing. Verified on 1.11-1.1: outputs "kvm".
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/RHEA-2011-1556.html
*** Bug 769010 has been marked as a duplicate of this bug. ***