Project

General

Profile

Bug #10787

Xen domU detection issues with pvops kernels.

Added by Florian Heigl 7 months ago. Updated about 1 month ago.

Status:
Released
Priority:
N/A
Assignee:
-
Category:
Agent
Target version:
Target version (plugin):
Severity:
Major - prevents use of part of Rudder | no simple workaround
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Very Small
Priority:
64

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

Bug #11621: Error in parent ticket upmergeReleasedBenoît PECCATTE

Associated revisions

Revision 5fba5030
Added by Janos Mattyasovszky 2 months ago

Fixes #10787: Xen domU detection issues with pvops

History

#1 Updated by François ARMAND 7 months ago

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

#2 Updated by François ARMAND 7 months ago

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

#3 Updated by François ARMAND 7 months 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

#4 Updated by Vincent MEMBRÉ 6 months ago

  • Target version changed from 3.1.21 to 3.1.22

#5 Updated by Benoît PECCATTE 6 months ago

  • Priority changed from 36 to 52

#6 Updated by Vincent MEMBRÉ 4 months ago

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

#7 Updated by Alexis MOUSSET 4 months ago

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

#8 Updated by Florian Heigl 4 months 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.

#9 Updated by Florian Heigl 4 months ago

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

#10 Updated by Florian Heigl 4 months 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... :-)

#11 Updated by Vincent MEMBRÉ 3 months ago

  • Target version changed from 3.1.23 to 3.1.24

#12 Updated by Florian Heigl 3 months 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.

#13 Updated by François ARMAND 2 months 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.

#14 Updated by Janos Mattyasovszky 2 months ago

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

#15 Updated by Janos Mattyasovszky 2 months ago

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

#16 Updated by Janos Mattyasovszky about 2 months ago

  • Status changed from New to Pending release
  • Priority changed from 65 to 64

#17 Updated by Vincent MEMBRÉ about 1 month ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.1.24, 4.1.8 and 4.2.1 which were released today.

Also available in: Atom PDF