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

Bug #2067

Virtual fact does not work for Xen, HyperV, kvm

Added by Gary Law over 5 years ago. Updated almost 3 years ago.

Status:ClosedStart date:03/11/2009
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:library
Target version:1.6.2
Keywords:Virtual
VMWare
Zones
Xen
HyperV
kvm
Affected Facter version:
Branch:

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

Hi

The ‘virtual’ fact seems to report only for vmware. See the following from the mailing list (re Xen):

2009/3/9 Trevor Hemsley trevor.hemsley@codefarm.com manufacturer => Xen virtual => physical

It appears that $virtual doesn’t work on Xen :(

It appears it doesn' work under Debian/Windows HyperV either:–

glaw@dv01:~ $ sudo facter virtual physical glaw@dv01:~ $ sudo facter -v 1.5.1 glaw@dv01:~ $ sudo facter operatingsystem Debian glaw@dv01:~ $

It also doesn’t seem to recognise a Solaris zone as a virtual, although it’s arguable if it is or not:–

glaw@sv01:~ $ facter -v 1.5.2 glaw@sv01:~ $ facter operatingsystem Solaris glaw@sv01:~ $ sudo facter virtual glaw@sv01:~ $

To detect a non-Global zone on Solaris, run the zonecfg command as root — it will return exit code 1:–

glaw@sv01:~ $ zonecfg zonecfg can only be run from the global zone. glaw@sv01:~ $ echo $? 1

Not sure how to detect HyperV or Xen.

Gary


Related issues

Related to Facter - Feature #9295: Detect Microsoft Hyper-V from guests Closed 09/01/2011
Related to Facter - Feature #19761: Virtual fact is not supported on Windows Closed

History

#1 Updated by Gary Law over 5 years ago

more from the list:–

2009/3/11 Avi Miller avi.miller@gmail.com

Trevor Hemsley wrote:

It appears that $virtual doesn’t work on Xen :(

It does for me. I get $virtual = xenu or xen0 on my boxes. Will have to check the exact Facter version, but I can tell you it’s whatever’s in EPEL.

#2 Updated by Felix Schäfer over 5 years ago

  • Subject changed from Virtual fact does not work for Xen or HyperV to Virtual fact does not work for Xen, HyperV, kvm
  • Keywords changed from Virtual VMWare Zones Xen HyperV to Virtual VMWare Zones Xen HyperV kvm

Doesn’t seem to work well from a kvm vm either. Here the interesting facter bits:

facterversion => 1.5.4
lsbdistdescription => Ubuntu 8.04.2
physicalprocessorcount => 0
processor0 => QEMU Virtual CPU version 0.9.1
processor1 => QEMU Virtual CPU version 0.9.1
processorcount => 2
productname => Not Specified
rubyversion => 1.8.6
virtual => physical

Feel free to ping me if you need more info. I’m not sure how much time I can spend testing stuff in the next few days/weeks, but I could at least provide the devs an internet-reachable kvm machine with whichever distribution they see fit.

#3 Updated by Peter Meier over 5 years ago

I think that this could be somehow related to the problem I encountered in #2011 , as this have been as well on a debian system. It looks like debian systems have other entries in /proc which will result in failing. At least this have been the problem in #2011 .

So anybody who encounters this bug, hence have the necessary systems, could try to debug the fact and see why it fails? You’ll find all the logic how facter decides what kind of system it is in lib/facter/virtual.rb and there isn’t much magic. I suspect that the necessary /proc entries or further things are missing, named differently or just in another location.

#4 Updated by James Turnbull over 5 years ago

  • Category set to library
  • Status changed from Unreviewed to Accepted
  • Assignee set to Puppet Community
  • Target version set to 30

#5 Updated by Adrian Bridgett over 5 years ago

We use this which returns QEMU for both QEMU and KVM – sorry, no way to tell them apart AFAIK:

if FileTest.exists?(“/proc/cpuinfo”) txt = File.read(“/proc/cpuinfo”) result = “qemu” if txt =~ /QEMU/ end

#6 Updated by James Turnbull over 5 years ago

  • Target version changed from 30 to 1.5.5

#7 Updated by James Turnbull over 5 years ago

  • Target version changed from 1.5.5 to 1.6.0

#8 Updated by Dick Davies about 5 years ago

I get a similar problem with VirtualBox (Centos 5.3 guest, Virtualbox 2.2.4 on OSX). Facter is the latest EPEL version

On VirtualBox, things are screwy:

[root@shoemaker ~]# facter manufacturer innotek GmbH [root@shoemaker ~]# facter virtual physical [root@shoemaker ~]# facter productname [root@shoemaker ~]# facter | grep productname productname => VirtualBox [root@shoemaker ~]#

(this is on the puppet + facter that are in EPEL:

root@shoemaker ~]# rpm -qa | egrep ‘(puppet|facter)’ puppet-0.24.8-1.el5.1 puppet-server-0.24.8-1.el5.1 facter-1.5.4-1.el5 [root@shoemaker ~]#

#9 Updated by James Turnbull about 5 years ago

  • Assignee deleted (Puppet Community)

#10 Updated by Tais Hansen about 5 years ago

Gary Law wrote:

Not sure how to detect HyperV or Xen.

At least with kernel 2.6.30 and kvm-88 the “hypervisor” flag is set in cpuinfo cpu flags inside kvm guests. I’m also seeing patches here and there to add a “hypervisor” field to cpuinfo to show which hypervisor (ie. kvm, vmware, etc) but it doesn’t seem to be accepted in the kernel yet.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 3
model name      : Pentium II (Klamath)
stepping        : 3
cpu MHz         : 2493.908
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic sep pge cmov mmx fxsr sse sse2 pni hypervisor
bogomips        : 4987.81
clflush size    : 32
power management:

#11 Updated by intrigeri - almost 4 years ago

This has been fixed for KVM in 1.5.8, thanks to Git commit 62b6773. (Distributors, please note that this patch applies flawlessly on 1.5.7 and works well there too.)

Splitting this bug report into more specific ones (Xen, HyperV and kvm) would help tracking this I guess.

#12 Updated by MaxiM Basunov over 3 years ago

facterversion => 1.5.8
interfaces => eth0,eth0_1,eth0_2,eth0_3,eth1
is_virtual => true
kernelrelease => 2.6.18-294.26.1.el5.lve0.7.49
lsbdistdescription => CentOS release 5.5 (Final)
virtual => openvzve

But this is hardware node without OpenVZ/Virtuozzo.

PS Facter from gem.

#13 Updated by Michael Stahnke about 3 years ago

  • Target version changed from 1.6.0 to 144

#14 Updated by Adrien Thebo almost 3 years ago

  • Status changed from Accepted to Closed
  • Xen dom0/domU detection fixed in #2747
  • HyperV support added for #9295
  • Solaris zone is_virtual detection added in #5016
  • OpenVZ detection improved in #6728 and #7959

Any bugs against virtualization detection should get a new ticket.

#15 Updated by Ken Barber almost 3 years ago

  • Target version changed from 144 to 1.6.2

Also available in: Atom PDF