RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 707524 - virt-what not detecting kvm guests because cpu model does not contain 'QEMU' string
Summary: virt-what not detecting kvm guests because cpu model does not contain 'QEMU' ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-what
Version: 6.1
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 769010 (view as bug list)
Depends On: 647862 672211
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-25 10:20 UTC by Richard W.M. Jones
Modified: 2011-12-20 12:32 UTC (History)
13 users (show)

Fixed In Version: virt-what-1.11-1.1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 647862
Environment:
Last Closed: 2011-12-06 09:57:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:1556 0 normal SHIPPED_LIVE virt-what bug fix and enhancement update 2011-12-06 00:39:22 UTC

Description Richard W.M. Jones 2011-05-25 10:20:27 UTC
+++ 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 on 2010-10-29 14:09:53 EDT ---

VM: virt-what-1.3-3.fc13.i686

--- Additional comment from rjones 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 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 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 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 on 2010-10-29 16:16:22 EDT ---

Patch works for my testing of kvm guests.

--- Additional comment from rjones 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 on 2011-05-24 13:36:54 EDT ---

Bump this up to Rawhide, not fixed upstream.

--- Additional comment from pbonzini 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 on 2011-05-25 05:34:36 EDT ---

*** Bug 707352 has been marked as a duplicate of this bug. ***

--- Additional comment from rjones 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 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.

Comment 2 Richard W.M. Jones 2011-05-26 07:41:46 UTC
By the way, I have not verified that this bug happens
in RHEL 6.1.  This bug is just a placeholder.

Comment 3 Richard W.M. Jones 2011-07-12 10:37:48 UTC
Should be automatically fixed because of the rebase
(bug 672211).

Comment 6 Jinxin Zheng 2011-07-19 05:20:00 UTC
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".

Comment 7 errata-xmlrpc 2011-12-06 09:57:53 UTC
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

Comment 8 Martin Cermak 2011-12-20 12:32:44 UTC
*** Bug 769010 has been marked as a duplicate of this bug. ***


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