Project

General

Profile

Actions
Copy link

Bug #10787

closed

Xen domU detection issues with pvops kernels.

Added by Florian Heigl almost 7 years ago. Updated over 6 years ago.

Status:
Released
Priority:
N/A
Assignee:
-
Category:
Agent
Target version:
3.1.24
Pull Request:
https://github.com/Normation/rudder-t...
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Very Small
Priority:
64
Name check:
Fix check:
Regression:

Description

It seems someone at CFEngine has been sleeping at the wheel.

All xen-related classes are not detected if the system is running a PVOps kernel.
This is quite unfortunate, Xen went upstream like 5 years ago...

@ # dmesg | grep -i " Hypervisor detected: Xen"
[ 0.000000] Hypervisor detected: Xen
  1. find /proc/xen/
    /proc/xen/ # ls /proc/xen/
  2. ls -d /proc/xen
    /proc/xen
  3. find /proc/xen
    /proc/xen
  4. dmesg | grep -i " Hypervisor detected: Xen"
    [ 0.000000] Hypervisor detected: Xen
  5. cf-promises --show-classes | grep -i xen
    #@

I've re-tested the whole thing with a 4.1.0 agent.
Same issue.

Please convince the CFEngine guys to detect existance of /proc/xen at the very least. If it does contain the file 'control_d' you're in a dom0.
Easiest way (no knowledge required) to detect a domU is by looking at /sys/module - if there's a number of xen_blkfront or xen_netfront drivers loaded, you are likely in a Xen domU with loaded PV drivers. No matter if full PV or HVM or PVHVM.

There are likely better ways but i think the discussion about "better" is best handled when the basics (it is detected at all) are restored.

Subtasks 1 (0 open — 1 closed)

Bug #11621: Error in parent ticket upmergeReleasedBenoît PECCATTEActions
Actions
Copy link

Also available in: Atom PDF