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.
VM: virt-what-1.3-3.fc13.i686
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.
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)?
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.
Created attachment 456553 [details] Patch to ignore /proc/cpuinfo in QEMU/KVM test Suggested patch.
Patch works for my testing of kvm guests.
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.
Bump this up to Rawhide, not fixed upstream.
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.
*** Bug 707352 has been marked as a duplicate of this bug. ***
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.
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.
virt-what-1.10-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/virt-what-1.10-1.fc15
Package virt-what-1.10-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing virt-what-1.10-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/virt-what-1.10-1.fc15 then log in and leave karma (feedback).
virt-what-1.10-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.