Bug #10787: Xen domU detection issues with pvops kernels. - Rudder - Issue Tracker

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:

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

find /proc/xen/
/proc/xen/ # ls /proc/xen/
ls -d /proc/xen
/proc/xen
find /proc/xen
/proc/xen
dmesg | grep -i " Hypervisor detected: Xen"
[ 0.000000] Hypervisor detected: Xen
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)

Actions

Copy link

Updated by François ARMAND almost 7 years ago

Related to Bug #10779: Memory detection of Xen hosts is incorrect added

Actions

Copy link

Updated by François ARMAND almost 7 years ago

Related to deleted (Bug #10779: Memory detection of Xen hosts is incorrect)

Actions

Copy link

Updated by François ARMAND almost 7 years ago

Target version set to 3.1.21
Severity changed from Minor - inconvenience | misleading | easy workaround to Major - prevents use of part of Rudder | no simple workaround
Priority changed from 0 to 36

Actions

Copy link

Updated by Vincent MEMBRÉ almost 7 years ago

Target version changed from 3.1.21 to 3.1.22

Actions

Copy link

Updated by Benoît PECCATTE almost 7 years ago

Priority changed from 36 to 52

Actions

Copy link

Updated by Vincent MEMBRÉ over 6 years ago

Target version changed from 3.1.22 to 3.1.23
Priority changed from 52 to 50

Actions

Copy link

Updated by Alexis Mousset over 6 years ago

Xen detection logic is improved in 4.1.7 (https://github.com/cfengine/core/commit/5a3de6f8e81b476c136ef408af54c978933ca02c), this may be fixed now.

Actions

Copy link

Updated by Florian Heigl over 6 years ago

We just found this bug again (I had forgotten...) just two days ago.
Gonna test a 4.1.7 agent on the system in question.

Actions

Copy link

Updated by Florian Heigl over 6 years ago

Don't got a 4.1.7 package in our mirror yet.
Is there a a published RPM already?

Actions

Copy link

#10

Updated by Florian Heigl over 6 years ago

It's a lot closer, but still crap.

Good:

xen is raised, this is correct.

Bad:

xen_domu is not raised.
xen_domu_hv is raised and wrong.

PVops kernel is a PV domU (non-CPU-assisted)
HV would mean a CPU-assisted VM which is not the case.
It is possible that they can't tell it apart, but TBH it looks like no serious effort has been made or the CFEngine guys would have noticed this.
There's just 4 common cases to test, and I think only part of that has been tested.

# cf-promises --show-classes | grep -i xen xen inventory,attribute_name=Virtual host,source=agent,hardclass xen_domu_hv source=agent,hardclass

Ideally they'd support:

xen
xen_dom0
xen_domu
xen_domu_pv (classic or pvops)
xen_domu_hv
xen_domu_pvh

A limited solution would be:

xen
xen_dom0
xen_domu

I dare say that incorrect detection is useless, and the current hv detection is simply wrong and useless.
Besides that, it's nice to see that it's again able to detect xen at all.

But that's like saying thank you for putting the roof back on the house... :-)

Actions

Copy link

#11

Updated by Vincent MEMBRÉ over 6 years ago

Target version changed from 3.1.23 to 3.1.24

Actions

Copy link

#12

Updated by Florian Heigl over 6 years ago

Note this also breaks the agent inventory because rudder doesn't have policy for hv xen.
I can't even...

Modify like this to fix:
SuSE.(xen_domu_pv|xen_domu_hv)::
"xen_tools_package" string => "xen-tools-domU";

Can we please at least have that.

Actions

Copy link

#13

Updated by François ARMAND over 6 years ago

Effort required set to Very Small
Priority changed from 50 to 65

The proposed evolution is very small and should be done.
I'm also very tempted to put it as "getting started", because lots of serious companies have virtualisation done with Xen.

Actions

Copy link

#14

Updated by Janos Mattyasovszky over 6 years ago

Pull Request set to https://github.com/Normation/rudder-techniques/pull/1202

PR at https://github.com/Normation/rudder-techniques/pull/1202

Actions

Copy link

#15

Updated by Janos Mattyasovszky over 6 years ago

Pull Request changed from https://github.com/Normation/rudder-techniques/pull/1202 to https://github.com/Normation/rudder-techniques/pull/1203

PR rebased against 3.1:
https://github.com/Normation/rudder-techniques/pull/1203

Actions

Copy link

#16