Detecting OpenVZ environment (hardware node or container)

[lpefferkorn]

Add hard classes _openvz_hardware_node_ and _openvz_container_ accordingly if we are in an OpenVZ environment:

On an hardware node:

# cf-promises/cf-promises -v | hcgrep openvz
openvz_hardware_node

Inside an OpenVZ container:

# cf-promises/cf-promises -v | hcgrep openvz
openvz_container

Tested on version 2.5 of OpenVZ

[dottedmag]

We need to think about proper names of classes and variables before merging such changes: there are lots of virtualization technologies, so we need a clear scheme for naming things.

[lpefferkorn]

Is the wiki the right place for this kind of work ?

[dottedmag]

Yes, it is.

[tzz]

@vohi any progress on this one? Can I help?

[kacf]

@tzz: Maybe you could draft up some basic guidelines for naming, like dottedmag suggests. Doesn't have to be very advanced, just something so that naming is not totally random.

[dottedmag]

Also, note CFEngine already has something for Xen. Existing class will have to stay, but Xen will need to have it in the same scheme.

I'd suggest 'guest_@name@', with the following @name@s: openvz, lxc, vmware (maybe also guest_vmware_@exacttype@), bochs, qemu, kvm, parallels (also maybe guest_parallels_@exacttype@), virtualbox, virtualpc.

Also 'host_@name@', where appropriate (xen, openvz).

Also, have a look at old bugtracker -- there is a bug with links on how to detect various virtualization technologies: https://cfengine.com/bugtracker/view.php?id=1192

[tzz]

It would be easier to support this if we had the ability to tag classes with their provenance. See https://cfengine.com/dev/issues/1895

I propose using namespaces, since they apply to classes as well. Then we can use classesmatching to easily enumerate them (unless the recent work from @sigurdteigen breaks that).

e.g. following @dottedmag suggestion:

• virt:openvz: in an OpenVZ environment.
• virt:guest_openvz
• virt:host_openvz

And similarly

• platform:solaris
• platform:x86_64
• platform:pure_debian

and so on... basically box platform discovery into a namespace so it doesn't pollute the top namespace. We'll still have quite a few classes in the default namespace for backwards compatibility, but I think namespacing new discovery modules is a good idea.

[kacf]

Sounds like a good idea!

[tzz]

With #847 in the core, this can be rewritten as a module (shell script, ideally) and populate the sys (or something similar) bundle as needed. It can still be loaded at startup, but doesn't have to be in C anymore. What do you think, @vohi @phnakarin ? It would be a three-liner compared to the current implementation, and probably much easier to extend further. It will need documentation regardless.

My suggestion about namespacing classes under virt is still pertinent.

[jooooooon]

I must second @tzz on this suggestion. Having this kind of discovery code in shell/Perl/Python/other-simple-well-know-scripting-language is infinitely nicer than having it hardcoded in C.

The advantages to my eyes are numerous: easier to hack, therefore encouraging more contributions to fix/extend it, also enabling users to change/fix/patch it without recompiling the whole agent, easier to debug/understand what is/isn't working...

[dottedmag]

There's one little issue: issuing assembler instruction CPUID is a little bit non-trivial in shell/Perl/Python/whatever.

[jooooooon]

@dottedmag, actually we have a script in Rudder to do just that: https://github.com/Normation/rudder-techniques/blob/master/tools/cpuid-linux-V1.0.sh. We're happy to contribute it to CFEngine, of course.

[tzz]

Obviously some discovery code can still live in C. My proposal is only for things like this request, trivial in shell but harder in C (e.g. dealing with line endings, parsing /etc/issue, and so on).

[tzz]

The ideal implementation for me would be to have sysinfo.c run the module protocol on a hard-coded list of modules, so both cf-promises and cf-agent will load them.

[tzz]

I can think of two issues:

• sites may not want to pay the startup penalty of running a shell script. sysinfo.c should be OK with missing scripts. We may even ship them disabled by default (a la Apache modules).
• security concerns: these discovery scripts have to be protected from attackers.

[cduclos]

Can one of the admins verify this patch?

[cduclos]

Can one of the admins verify this patch?

[ncharles]

I'd add that, on top of the discovery part, we also need to be able to change some hardcoded paths.
for instance, for an OpenVZ container, the ps command returns processes on all host, making the process: promise type unusable.
If we could, in promises (or somewhere else?) define the command to execute based on classes (like running vzps -E 0 )

[ncharles]

Just a remark, this pull request scans the content of the file /proc/self/status for certains strings; however, it seems that it could be easier by:

• checking if file /proc/bc/0 exists, then define the class openvz_hardware_node
• else, if file /proc/vz exists, then define openvz_container

This works for OpenVZ/Virtuozzo/Parallels Cloud Server

[ncharles]

Based on the discussions there, and inspired by @lpefferkorn 's code, I created the Pull Request #949
The new pull request adds also the use of the tool vzps when available, so that the processes promise type can be functional on OpenVZ host (the host sees the processes of all the guest)
So I think this pull request can be closed.

Thank you !

[cduclos]

Can one of the admins verify this patch?

[kacf]

Superseded by #949.

[kacf]

Err... superseded by #956.