Bug #2169

xen domu/dom0 fact broken on new xen kernels

Added by Adrian Bridgett about 3 years ago. Updated about 3 years ago.

Status:Closed Start date:04/17/2009
Priority:Normal Due date:
Assignee:Puppet Community % Done:

100%

Category:library
Target version:1.5.5
Keywords: Affected Facter version:
Branch:
Votes: 0

Description

(see #1558 too)

I’m running 2.6.26 dom0 and domU under Xen.

On the host both /proc/sys/xen/independent_wallclock and /proc/xen/capabilities exist, on the guest, neither exist.

I can’t see anything else under /proc/ on DomU, however /sys/bus/xen exists on both (/sys/bus/xen-backend exists on the dom0 but I believe this could also exist in DomUs providing devices to other domUs).

I now use this snippet of code:

    # new Xen domains have this in dom0 not domu :(
    if FileTest.exists?("/proc/sys/xen/independent_wallclock")
      result = "xenu"
    end
    if FileTest.exists?("/sys/bus/xen")
      result = "xenu"
    end
    if FileTest.exists?("/proc/xen/capabilities")
      txt = File.read("/proc/xen/capabilities")
      if txt =~ /control_d/i
        result = "xen0"
      end
    end

without this, the dom0 was reported as xenu and the domUs were not reported as being under xen at all


Related issues

related to Facter - Bug #4508: Facter does not recognise Xen HVM DomU Closed 08/10/2010
related to Facter - Bug #7723: virtual xenu incorrectly detected on newer kernels. Needs Decision 05/31/2011

History

Updated by Paul Gear about 3 years ago

I can confirm this bug on my Debian lenny system (facter 1.5.1-0.1). My dom0 is incorrectly reported as xenu, and if i patch the facter code to use the snippet shown above, it works correctly.

Updated by James Turnbull about 3 years ago

  • Category set to library
  • Status changed from Unreviewed to Accepted
  • Assignee set to James Turnbull
  • Target version set to 1.5.5

Updated by James Turnbull about 3 years ago

  • Status changed from Accepted to Closed

Pushed in commit:7b1e41cdbfab4e02777ef9f05b18dbc919d6adbe in branch master.

Updated by James Turnbull about 3 years ago

  • Status changed from Closed to Re-opened
  • Assignee changed from James Turnbull to Puppet Community
  • Target version changed from 1.5.5 to 30

Can someone check this code? It doesn’t seem logical to me. Is there a simpler way of determining the xenu xen0 difference?

Updated by Adrian Bridgett about 3 years ago

I think part of the problem is that what you see has changed between different Xen versions.

The second part being the only way I could see on new domUs to tell that it was a Xen domain.

The 3rd part being a tighter version of the original code which won’t set dom0s as domUs.

The first part being the old way to detect domUs which I left in as I didn’t know if the second part worked on old Xen Domus.

Updated by James Turnbull about 3 years ago

  • Target version changed from 30 to 1.5.5

Updated by James Turnbull about 3 years ago

  • Status changed from Re-opened to Closed
  • % Done changed from 0 to 100

Applied in changeset commit:7b1e41cdbfab4e02777ef9f05b18dbc919d6adbe.

Also available in: Atom PDF