Puppet » Facter

Ben Hughes wrote:

Is this for the virtual fact?

is_virtual improperly set to “true”, must be “false” virtual improperly set to “openvzve”, must be “physical”

Is CloudLinux not just a distro running atop of openvz?

No… Portions based on VZ, so /proc/user_beancounters present and directory /proc/vz present. But no VZ tools, no other files in /proc/vz/… So, CloudLinux host is not an VZVE.

CloudLinux position itself as “lightweight virtual environment (LVE)”: – LVE is an isolation technology that increases server density, stability and reliability. LVE limits the amount of resources (CPU, I/O and memory) available to a specific process or customer. It is a lightweight and transparent shell. LVE wraps the accounts on a shared server to give hosting providers control over CPU resources.

So, LVE has no containers in terms of VZ, and it always run on physical host.

Any updates?

Is parsing /etc/redhat-release the best way to tell if a sysadmin is a Cloudlinux system?

No. System is still “CentOS release 5.5 (Final)” from /etc/redhat-release.

I didn’t change the operatingsystem value as there’s current a discussion about that in https://projects.puppetlabs.com/issues/6679 and possible breakage people will suffer when changing that value when they rely on it being a certain value, and then changing it under their feet.

That discussion is at https://projects.puppetlabs.com/issues/6792 too.

If you’d be so kind as to test it on your systems to see if it works for you, please check out https://github.com/barn/facter/tree/ticket/next/6728-facter_improperly_detects_openvzve_on_cloudlinux_systems

I just patched one of our CL systems with your patch, and confirm that it is working properly:

# uname -r
2.6.18-294.26.1.el5.lve0.8.18
# facter -p virtual is_virtual
is_virtual => false
virtual => physical

Thank you. Awaiting for release.

I didn’t change the operatingsystem value as there’s current a discussion about that in https://projects.puppetlabs.com/issues/6679 and possible breakage people will suffer when changing that value when they rely on it being a certain value, and then changing it under their feet.

We also point our logic to analyze for words RedHat/CentOS in operatingsystem, so we don’t require for such major changes.

Great. Thanks for testing it.

I fear it won’t make it in until 1.6.0 as we’re in release candidate stages for 1.5.9.

Merged into next branch in commit:8353506ea5705a58ed4bf91283e475751fb5f77c

Guys, this broke OpenVZ VE detection. /proc/vz/veinfo does not exist in VEs, so virtual will now never return “openvzve”.

Please check #2242, Christian outlined a rock-solid solution for solving the OpenVZ detection once and for all.

As for Cloudlinux – using OpenVZ, having a CentOS release tag and expecting that this is detected as something discrete is somewhat amusing. Please don’t ride on side-effects to have your detection work, OpenVZ is already big in this game :/.

The main distributions would be

RHEL/CentOS through third party kernels and userland tool, for both OpenVZ and Virtuozzo (commercial variant)

and

Debian, ships with kernels and tools which are co-maintained by Debian and OpenVZ upstream developers; supports only OpenVZ

Both Ubuntu Server and SuSE never shipped a release with OpenVZ support to my knowledge, thirdparty support exists, in doubt expect behavior similar to Debian and RHEL respectively.

Thanks Ben, this looks good and should cover us for now. We’ll see where all this container business ventures in the future ;)

currently openvz systems with 2.6.32 doesn’t have /proc/vz/veinfo left. Probably relying on /proc/user_beancounters would be a good idea