The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #8210

virtual fact should work for EL kvm guests

Added by Markus Falb over 3 years ago. Updated over 1 year ago.

Status:ClosedStart date:07/03/2011
Priority:NormalDue date:
Assignee:Adrien Thebo% Done:

0%

Category:library
Target version:1.7.0
Keywords: Affected Facter version:1.6.2
Branch:https://github.com/puppetlabs/facter/pull/340

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

The Output from /proc/cpuinfo can not used reliable for telling that it is a kvm virtual machine. On a CentOS 5.6 kvm Host with CentOS guests /proc/cpuinfo tells me:

for a smp guest

model name  : QEMU Virtual CPU version 0.9.1

with only one cpu in the guest:

model name  : Pentium II (Klamath)

but in both cases:

$ dmidecode -t 4
...
Manufacturer: QEMU
...

I believe it is possible to specify what cpu is used so on the commandline, so relying on the model name is not always working

For more information please also have a look at
https://bugzilla.redhat.com/show_bug.cgi?id=707523

cpuinfo.txt Magnifier - Output ofcat /proc/cpuinfo on Ubuntu 11.10 running as a VirtualBox guest (2.55 KB) Jason Short, 01/21/2012 08:33 am


Related issues

Related to Facter - Bug #14366: virtual => physical and is_virtual => false on EC2 Closed 05/08/2012
Related to Facter - Bug #20054: virtual facts show error about gsub on nil Closed
Duplicated by Facter - Bug #10879: Does not detect KVM VM as a virtual machine when kvm prov... Duplicate 11/16/2011
Duplicated by Facter - Bug #16302: facter reports that RHEL6 VMs are physical Duplicate 09/07/2012 09/14/2012
Duplicated by Facter - Bug #10625: Xen dom0 and domU hosts reported as physical without xenf... Duplicate 11/08/2011
Duplicated by Facter - Bug #16559: virtual fact shows physical on KVM when copying the host CPU Duplicate 09/24/2012

History

#1 Updated by James Turnbull about 3 years ago

  • Status changed from Unreviewed to Investigating
  • Assignee set to Adrien Thebo

#2 Updated by James Turnbull about 3 years ago

  • Category set to library

#3 Updated by Adrien Thebo about 3 years ago

Relying on dmidecode would be a better way of handling this sort of lookup, but the manufacturer name is not guaranteed to be ‘QEMU’. I’ve found the following on a kvm hypervisor:

~# dmidecode -t 4
dmidecode 2.9
SMBIOS 2.4 present.

Handle 0x0401, DMI type 4, 32 bytes
Processor Information
        Socket Designation: CPU01
        Type: Central Processor
        Family: Other
        Manufacturer: Bochs
        ID: 33 06 00 00 FD AB 81 07
        Version: Not Specified
        Voltage: Unknown
        External Clock: Unknown
        Max Speed: 2000 MHz
        Current Speed: 2000 MHz
        Status: Populated, Enabled
        Upgrade: Other
        L1 Cache Handle: Not Provided
        L2 Cache Handle: Not Provided
        L3 Cache Handle: Not Provided

We’ll need better detection of the manufacturer regardless of the BIOS used.

#4 Updated by Markus Falb about 3 years ago

You could leave away the funny switches and just do

$ dmidecode
... look if you find something worthfully in this lot of information ...

I just found

$ dmidecode -t 1
...
    Product Name: KVM
...

or shorter

$ dmidecode -s system-product-name
KVM

#5 Updated by Bernhard Schmidt almost 3 years ago

This has become worse in 1.6.2, because in 1.6.1 the guest was at least (incorrectly, see bug #7723) detected as xenu and thus virtual.

This problem can be triggered by the libvirt feature “copy Host CPU configuration”, which replaces the “QEMU Virtual CPU…” string in /proc/cpuinfo with a real CPU description.

#6 Updated by Adrien Thebo almost 3 years ago

  • Assignee changed from Adrien Thebo to shubhra sinha varma

#7 Updated by Frederik Himpe almost 3 years ago

You can consider using virt-what. Version 1.11 gives the correct output on my system.

#8 Updated by Ken Barber almost 3 years ago

  • Target version set to 144
  • Affected Facter version set to 1.6.2

#9 Updated by Peter Meier almost 3 years ago

Could we consider this a critical bug? Querying facter to figure out, whether you’re on a guest or not is something that probably a lot of people are doing.

#10 Updated by Ken Barber almost 3 years ago

  • Status changed from Investigating to Accepted

Agreed its important – however I think the problem is specific to various systems/configurations only.

Firstly – I find it odd that the original described behaviour changed with 1 cpu versus 2 on a Centos 5.6 guest.

I obviously don’t get it in Debian – it represents the CPU as:

QEMU Virtual CPU version 0.14.1

Also dmidecode represents my manufacturer as ‘Boschs’, so using this won’t work, but it might be reasonable fall through for other systems.

For RHEL 6.1 (and I mean RHEL not Centos) I see:

QEMU Virtual CPU version (cpu64-rhel6)

So that works fine there as well. Interesting on RHEL6 I get:

Product Name: KVM

But this doesn’t work the same on Debian. Go figure.

Anyway – I wouldn’t mind a bit of a poll on this one … at the moment the confirmed operating system with this fault ‘in ticket’ is Centos 5.6. Any others with the exact same problem where /proc/cpuinfo is different? I just need to get an idea of what systems we’ll have to setup to test this.

#11 Updated by Jason Short almost 3 years ago

Facter also incorrectly detects physical/virtual machines running in VirtualBox, tested with an Ubuntu 11.10 guest. (Puppet 2.7.1) It happens on both SMP and single CPU guests.

The virt-what package does correctly return the value “virtualbox”, though I don’t like the idea of depending on that since it’s not installed by default.

#12 Updated by Jason Short almost 3 years ago

  • Status changed from Accepted to Closed

Facter 1.6.4, however, correctly reports the virtual and is_virtual facts under Ubuntu 11.10

Facter 1.6.2 on Centos 5.7 also works. (My previous test was with 1.5.9)

#13 Updated by Markus Falb almost 3 years ago

Jason Short wrote:

Facter 1.6.2 on Centos 5.7 also works. (My previous test was with 1.5.9)

No, it does not!

# rpm -q facter
facter-1.6.2-1.el5
# cat /proc/cpuinfo|grep "model name"
model name  : Pentium II (Klamath)
# facter virtual
physical

#14 Updated by Markus Falb almost 3 years ago

  • Status changed from Closed to Re-opened

#15 Updated by Markus Falb almost 3 years ago

As I understand, it only happens on 32bit guests.

#16 Updated by Gonzalo Servat almost 3 years ago

Same problem here:

  • RHEL 6.1 (64bit) with 2 vCPUs: model name is QEMU Virtual CPU, thus facter virtual == kvm
  • CentOS 6.2 (64bit) with 1 vCPU: model name is QEMU Virtual CPU, thus facter virtual == kvm
  • RHEL 5.7 (32bit) with 2 vCPUs: model name is Pentium II (Klamath), thus facter virtual == physical

FWIW, virt-what reports “kvm” correctly on all 3 systems. Bit of an issue now as I was relying on the value of virtual for a few things. What’s the plan of attack?

#17 Updated by Damian Szeluga over 2 years ago

The same problem is on OpenIndiana:

root@s11326.dc2:~# uname -a
SunOS s11326.dc2 5.11 oi_151a i86pc i386 i86pc Solaris
root@s11326.dc2:~# facter -v
1.6.4
root@s11326.dc2:~# prtdiag | grep System
System Configuration: Bochs Bochs
root@s11326.dc2:~# facter -p | grep virtual
is_virtual => true
virtual => physical

#18 Updated by Andreas Zuber over 2 years ago

On RedHat/CentOS KVM hosts the guest sees the processor manufacture “Bochs”. I tested this with Centos, Ubuntu and FreeBSD, the model name seams to depend on the architecture while the manufacturer remains “Bochs”. What i could not test was if that works on Non-RedHat KVM hosts.

diff --git a/lib/facter/util/virtual.rb b/lib/facter/util/virtual.rb
index aed961e..91bad24 100644
--- a/lib/facter/util/virtual.rb
+++ b/lib/facter/util/virtual.rb
@@ -53,12 +53,8 @@ module Facter::Util::Virtual
end
def self.kvm?
-     txt = if FileTest.exists?("/proc/cpuinfo")
-       File.read("/proc/cpuinfo")
-     elsif ["FreeBSD", "OpenBSD"].include? Facter.value(:kernel)
-       Facter::Util::Resolution.exec("/sbin/sysctl -n hw.model")
-     end
-     (txt =~ /QEMU Virtual CPU/) ? true : false
+    processor_manufacturer = Facter::Util::Resolution.exec("/usr/sbin/dmidecode -s processor-manufacturer")
+    processor_manufacturer.include? 'Bochs'
end
def self.virtualbox?

Branch for pull is here: git://github.com/ZeroPointEnergy/facter.git

#19 Updated by Markus Falb over 2 years ago

Andreas Zuber wrote:

On RedHat/CentOS KVM hosts the guest sees the processor manufacture “Bochs”. I tested this with Centos, Ubuntu and FreeBSD, the model name seams to depend on the architecture while the manufacturer remains “Bochs”. What i could not test was if that works on Non-RedHat KVM hosts.

On my guests it does not say Bochs

# /usr/sbin/dmidecode -s processor-manufacturer
QEMU

Both bochs and qemu could run without kvm, couldnt they?

#20 Updated by Andreas Zuber over 2 years ago

What KVM host and what guest OS did you use?

#21 Updated by Markus Falb over 2 years ago

Andreas Zuber wrote:

What KVM host and what guest OS did you use?

The same as it was when I reported this issue, 64 bit CentOS host (of course), 32 bit CentOS guest, but now it is not at 5.6 anymore but 5.7. I believe it was at 5.4 when I created the guest, not quite sure though.

And I remembering changing the machine type some months before, but after this ticket was raised.

<os>
<type arch='i686' machine='rhel5.6.0'>hvm</type>

#22 Updated by Satoru KURASHIKI over 2 years ago

hi,

Andreas Zuber wrote:

def self.kvm?
-     txt = if FileTest.exists?("/proc/cpuinfo")
-       File.read("/proc/cpuinfo")
-     elsif ["FreeBSD", "OpenBSD"].include? Facter.value(:kernel)
-       Facter::Util::Resolution.exec("/sbin/sysctl -n hw.model")
-     end
-     (txt =~ /QEMU Virtual CPU/) ? true : false

end

How about this instead of checking proc?

  txt = `lscpu 2>/dev/null`
  (txt =~ /KVM/) ? true : false

Most of linux guests would have lscpu (within util-linux), and it has output like:

Hypervisor vendor:     KVM

#23 Updated by Andrew Elwell over 2 years ago

Most of linux guests would have lscpu (within util-linux)

Sadly not for RHEL 5 clones (SL / centos / SLC) — the util-linux bundled with these is too old

# rpm -ql util-linux | grep cp
# facter operatingsystemrelease
5.8
# rpm -q util-linux
util-linux-2.13-0.59.el5.x86_64

compared to SL6:

# rpm -qf `which lscpu`
util-linux-ng-2.17.2-12.4.el6.x86_64
# facter operatingsystemrelease
6.2

#24 Updated by Markus Falb over 2 years ago

I found a discussion in http://www.mail-archive.com/kvm@vger.kernel.org/msg02738.html that lead to a discussion in http://www.mail-archive.com/puppet-dev@googlegroups.com/msg03959.html, several years ago.

My summary of this topic would be like

  • The only reliable way to detect KVM virtual machine is to leverage the CPUID instruction.
  • If this should be implemented in facter itself or if facter use another library is a design decision.
  • Personally I would guess that 3rd party tools like virt-what are just doing that CPUID thing.
  • Typically not every tool is packaged for every OS, this is the problem with 3rd party tools.

Unfortunately workarounds are not reliable. As an example, the physicalprocessorcount fact changed its behaviour some time ago (but after this ticket was purchased). Another idea were the productname fact. But to be honest, I am quite sure this isn’t reliable too.

#25 Updated by Adrien Thebo over 2 years ago

  • Assignee deleted (shubhra sinha varma)

If I recall correctly, checking the CPUID instruction means having native compiled code – or at least, when I looked at virt-what it was building a tiny binary to do this detection. Considering facter can run on anything that ruby runs on, we would have to build a LOT of binaries for this detection, since it’s a little crazy to compile code upon package installation. Building this behavior into facter itself seems like a no-go.

We could have a resolution method that attempts to use virt-what if it’s available but falls back to other methods if it’s not present. However, I would expect that people would probably want virt-what as a required dependency and we try to keep facter light on dependency.

#26 Updated by Jeff Weiss over 2 years ago

  • Target version deleted (144)

#27 Updated by Zak Estrada over 2 years ago

Not sure if this helps, but I can definitely confirm that this bug exists for facter 2.0.0rc4 on RHEL 6.2 x86_64

Here’s /proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Westmere E56xx/L56xx/X56xx (Nehalem-C)
stepping        : 1
cpu MHz         : 2533.280
cache size      : 4096 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc unfair_spinlock pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm
bogomips        : 5066.56
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

As mentioned in Ticket 2067, the hypervisor flag is set as expected

#28 Updated by Orion Poplawski over 2 years ago

FWIW – virt-what is a pretty light-weight (232 total lines including comments) bash script that seems to only depend on dmidecode. If you don’t want to depend on it, maybe you just want to copy its logic into facter/ruby.

#29 Updated by Krzysztof Wilczynski over 2 years ago

Orion Poplawski wrote:

FWIW – virt-what is a pretty light-weight (232 total lines including comments) bash script that seems to only depend on dmidecode. If you don’t want to depend on it, maybe you just want to copy its logic into facter/ruby.

+1 for moving the logic into relevant bit of the resolver within Facter.

KW

#30 Updated by Ken Barber over 2 years ago

Orion Poplawski wrote:

FWIW – virt-what is a pretty light-weight (232 total lines including comments) bash script that seems to only depend on dmidecode. If you don’t want to depend on it, maybe you just want to copy its logic into facter/ruby.

virt-what has some C based helpers – virt-what-cpuid-helper.c is used to determine KVM/Xen I believe by accessing the cpuid, so its not entirely bash.

#31 Updated by Orion Poplawski over 2 years ago

Ken Barber wrote:

virt-what has some C based helpers – virt-what-cpuid-helper.c is used to determine KVM/Xen I believe by accessing the cpuid, so its not entirely bash.

Ah yes, somehow I missed that. At least that code is standalone too.

# /usr/libexec/virt-what-cpuid-helper
KVMKVMKVM

#32 Updated by Andreas Zuber about 2 years ago

I wrote another fact that checks if virt-what is installed and uses it’s output to determine the virtual machine type. The has_weight = 200 makes sure this fact is ran first. Don’t know if this is a good way to do it. Ideas, suggestions, rants?

https://github.com/ZeroPointEnergy/facter/commit/db59e104507a3db4c7a5578c975bb2f8939b146c

#33 Updated by Peter Meier about 2 years ago

  • Priority changed from Normal to High

Can we get an update here?

Facter not being able to properly determine on which kind of system we are is quite serious. virtual and is_virtual are core facts that for example determine, which kind of extra services (smartd, …) need to run on a system. So it should really get some more love here from the facter-developers. Thanks!

#34 Updated by Markus Falb about 2 years ago

Adrien Thebo wrote:

We could have a resolution method that attempts to use virt-what if it’s available but falls back to other methods if it’s not present.

If virt-what provides above mentioned interface to the CPUID instruction, well, all is good. If fall backs are acceptable depends. For kvm virtual machines, in my understanding, there are no reliable fall backs. I see only 2 solutions, you find a library that implements this CPUID beast or you do not and have it implemented yourself.

I do not know how it is with other Virtualization methods.

#35 Updated by Markus Falb about 2 years ago

Peter Meier wrote:

Can we get an update here?

After razor was introduced (which depends on facter) it seems much more important to me that facter acts reliable

#36 Updated by Jeff McCune about 2 years ago

  • Status changed from Re-opened to Investigating
  • Assignee set to Jeff McCune
  • Priority changed from High to Normal
  • Target version set to 1.6.x

Investigating

I’m getting up to speed on this issue now.

-Jeff

#37 Updated by Jeff McCune about 2 years ago

  • Status changed from Investigating to Accepted

#38 Updated by Jeff McCune about 2 years ago

OK, I think I’m up to speed.

First, the CPUID instruction isn’t a viable option because it’s way too close to the underlying hardware for us to maintain in a portable way.

Second, I’m going to limit the scope of this issue to fixing the virtual fact when running on enterprise linux >= 5 hypervisors (RHEL, CentOS). If you run into this problem on other operating systems, please create new ticket with the appropriate steps to reproduce the issue on those platforms and relate them to this issue.

The approach I’m going to take is to try and use virt-what if it’s present, then fall back to the other work-arounds in some documented order of preference until we’re able to get the desired value.

-Jeff

#39 Updated by Jeff McCune about 2 years ago

  • Subject changed from virtual => physical for kvm guests to virtual fact should work for EL kvm guests

#40 Updated by Jeff McCune about 2 years ago

Andreas Zuber wrote:

I wrote another fact that checks if virt-what is installed and uses it’s output to determine the virtual machine type. The has_weight = 200 makes sure this fact is ran first. Don’t know if this is a good way to do it. Ideas, suggestions, rants?

https://github.com/ZeroPointEnergy/facter/commit/db59e104507a3db4c7a5578c975bb2f8939b146c

Andreas,

This fact looks really good. I’d like to merge it into Facter core once I add some tests around it.

Would you mind signing the contributor license agreement so I can take your patch as-is?

Thanks, -Jeff

#41 Updated by Andreas Zuber about 2 years ago

Hi Jeff

I already signed that two years ago, so you should be ok merging the fact. If you need me to sign it again I will do it as fast as possible, just say so.

Good to see that merged, no need for us to maintain a patched RPM then :–)

Thanks Andreas

#42 Updated by Jeff McCune about 2 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch set to https://github.com/puppetlabs/facter/pull/340

#43 Updated by Jeff McCune about 2 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release
  • Assignee deleted (Jeff McCune)
  • Target version changed from 1.6.x to 1.6.14

Merged into 1.6.x, 2.x, master

As cf43fc0

This should be released in 1.6.14. Please give this a try.

Facter will automatically switch to using virt-what if it is available along the PATH.

-Jeff

#44 Updated by Peter Meier about 2 years ago

Jeff, I can confirm that the current HEAD (6cc0887db6a3a90115123990d7993495774bf0f6) which includes your fixes for kvm, fixes this problem.

Thanks!

#45 Updated by Jeff McCune about 2 years ago

Peter Meier wrote:

Jeff, I can confirm that the current HEAD (6cc0887db6a3a90115123990d7993495774bf0f6) which includes your fixes for kvm, also fixes this xen Problem.

Thanks!

Glad to hear it, thanks for following up.

-Jeff

#46 Updated by Matthaus Owens almost 2 years ago

  • Status changed from Merged - Pending Release to Closed

Released in Facter 1.6.14

#47 Updated by Andreas Ntaflos over 1 year ago

As reported some time ago in #16559 when copying the physical host’s CPU configuration into the KVM guest, facter is_virtual reports false and facter virtual reports phyical, even though it indeed is a virtual machine. This happens with Facter 1.6.17 and Puppet 3.1.0 on Ubuntu 12.04 (x86_64) both as host and guest, using KVM (currently 1.0+noroms-0ubuntu14.7) and Libvirt (0.9.8-2ubuntu17.7). In /proc/cpuinfo this looks as follows on the virtual machine/guest:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz
stepping        : 11
microcode       : 0x1
cpu MHz         : 3058.998
cache size      : 4096 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl pni vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm
bogomips        : 6117.99
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual

So it seems this the fix that made it into Facter 1.6.14 does not work universally. Can I provide anything to help debug and fix this further?

#48 Updated by eric sorenson over 1 year ago

  • Status changed from Closed to Re-opened
  • Assignee set to Adrien Thebo
  • Target version changed from 1.6.14 to 1.7.0

Andreas, thanks for the ping on this to let us know it’s not completely fixed. I’ll re-open this and assign to Adrien as he is looking at virtualisation facts for Facter 1.7.0 as part of #16278.

#49 Updated by eric sorenson over 1 year ago

  • Status changed from Re-opened to Closed

Never mind, Andreas reported that the failed host did not have virt-what installed. Code is working as expected when it’s installed.

#50 Updated by Markus Falb over 1 year ago

Maybe this is sufficient? No need for virt-what?

# dmidecode -s system-product-name
KVM

Also available in: Atom PDF