Bug #2169
xen domu/dom0 fact broken on new xen kernels
| Status: | Closed | Start date: | 04/17/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % 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
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.