Puppet » Facter

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.

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

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.

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

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.

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

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

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?

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

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

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?

What KVM host and what guest OS did you use?

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>

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

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

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.