OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Building LKM against OpenVZ kernel from RPM

2007-06-01T15:47:01Z

Mh720: /* Workaround */

Sometimes it is necessary to build LKMs (LKM - Linux Kernel Module) against OpenVZ kernels. If you have used RPM package for installing OpenVZ kernel and your kernel is not native for your distribution, you probably will expirience troubles. As a native distribution I designate the distribution, where OpenVZ kernel team builds the kernel. We have here the following policy: rhel4-based kernels are build on rhel4/centos4 distributions, rhel5-based kernels are build on rhel5/centos5 distributions. So, for example, the situation when you install rhel5-based OpenVZ kernel on rhel5/centos5 distribution considered to be kernel on a native distribution. But if you install rhel5-base OpenVZ kernel ont rhel4/centos4, then you have kernel on not native distriubution.

Mainstream-based OpenVZ kernels are not guaranteed to be build on some definite distribution, so there is no permanent predefined native distribution for such kernels.

Here is an example of errors the user obtain trying to build LKM against OpenVZ kernel on not native distribution:
<pre>
30855 Floating point exception| scripts/genksyms/genksyms -a x86_64 > /usr/local/src/zaptel-1.2.17.1/.tmp_zaptel-base.ver
/bin/sh: line 1: 527 Floating point exception scripts/basic/fixdep
/bin/sh: line 1: 2232 Floating point exception scripts/mod/modpost -m -a -i
</pre>

In this article I describe the reason of this problem and how to workaround it. Thank you to Mike Holloway for revealing the problem.

== The Reason ==
In order to build LKM you need kernel headers and some other information from kernel sources. This information is located in files in <tt>-devel</tt> package for rhel5-based kernels and is incorporated in rhel4-based kernel packages. In addition to headers these packages content some executable binaries in <tt>scripts</tt> subdirectory of build tree:
<pre>
$ rpm -qlp ovzkernel-2.6.9-023stab044.4.x86_64.rpm | grep scripts
/lib/modules/2.6.9-023stab044.4/build/scripts
/lib/modules/2.6.9-023stab044.4/build/scripts/.bin2c.cmd
/lib/modules/2.6.9-023stab044.4/build/scripts/.conmakehash.cmd
/lib/modules/2.6.9-023stab044.4/build/scripts/.kallsyms.cmd
...
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/docproc # << binary executable
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/docproc.c
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/fixdep # << binary executable
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/fixdep.c
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/split-include # << binary executable
...
... # << other binary executable
...
$ rpm -qlp ovzkernel-devel-2.6.18-8.1.3.el5.028stab033.1.x86_64.rpm | grep scripts
...
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/.bin2c.cmd
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/.conmakehash.cmd
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/.gitignore
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/.kallsyms.cmd
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/basic/docproc # << binary executable
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/basic/docproc.c
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/basic/fixdep # << binary executable
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/basic/fixdep.c
...
... # << other binary executable
...
</pre>

These executables are created while building kernel package on our build system. And they are linked to libc installed on the build system! Now imagine that you've installed OpenVZ kernel package based on rhel5 kernel, say, on rhel4 distribution. The binaries mentioned above are also installed, but they can't run on this node, because other libc is installed on this system!

== Workaround ==
The clean way to solve the problem is to [http://wiki.openvz.org/Kernel_build build the kernel from sources ]. Then all binaries will be linked with the libraries that are on your node and no problems will arise.

A dirty way to get past the problem is to replace all the scripts with ones from a distribution that matches your installed system. At a minimum, you will probably need to replace the files in these directories:

/usr/src/kernels/2.6.18-8.el5.028stab031.1-x86_64/scripts/genksyms 
/usr/src/kernels/2.6.18-8.el5.028stab031.1-x86_64/scripts/basic 
/usr/src/kernels/2.6.18-8.el5.028stab031.1-x86_64/scripts/mod

== Externals link ==
Appropriate bug report: http://bugzilla.openvz.org/show_bug.cgi?id=586

[[Category:HOWTO]]
[[Category:Troubleshooting]]

Building LKM against OpenVZ kernel from RPM

2007-06-01T15:45:38Z

Mh720: /* Workaround */

Sometimes it is necessary to build LKMs (LKM - Linux Kernel Module) against OpenVZ kernels. If you have used RPM package for installing OpenVZ kernel and your kernel is not native for your distribution, you probably will expirience troubles. As a native distribution I designate the distribution, where OpenVZ kernel team builds the kernel. We have here the following policy: rhel4-based kernels are build on rhel4/centos4 distributions, rhel5-based kernels are build on rhel5/centos5 distributions. So, for example, the situation when you install rhel5-based OpenVZ kernel on rhel5/centos5 distribution considered to be kernel on a native distribution. But if you install rhel5-base OpenVZ kernel ont rhel4/centos4, then you have kernel on not native distriubution.

Mainstream-based OpenVZ kernels are not guaranteed to be build on some definite distribution, so there is no permanent predefined native distribution for such kernels.

Here is an example of errors the user obtain trying to build LKM against OpenVZ kernel on not native distribution:
<pre>
30855 Floating point exception| scripts/genksyms/genksyms -a x86_64 > /usr/local/src/zaptel-1.2.17.1/.tmp_zaptel-base.ver
/bin/sh: line 1: 527 Floating point exception scripts/basic/fixdep
/bin/sh: line 1: 2232 Floating point exception scripts/mod/modpost -m -a -i
</pre>

In this article I describe the reason of this problem and how to workaround it. Thank you to Mike Holloway for revealing the problem.

== The Reason ==
In order to build LKM you need kernel headers and some other information from kernel sources. This information is located in files in <tt>-devel</tt> package for rhel5-based kernels and is incorporated in rhel4-based kernel packages. In addition to headers these packages content some executable binaries in <tt>scripts</tt> subdirectory of build tree:
<pre>
$ rpm -qlp ovzkernel-2.6.9-023stab044.4.x86_64.rpm | grep scripts
/lib/modules/2.6.9-023stab044.4/build/scripts
/lib/modules/2.6.9-023stab044.4/build/scripts/.bin2c.cmd
/lib/modules/2.6.9-023stab044.4/build/scripts/.conmakehash.cmd
/lib/modules/2.6.9-023stab044.4/build/scripts/.kallsyms.cmd
...
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/docproc # << binary executable
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/docproc.c
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/fixdep # << binary executable
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/fixdep.c
/lib/modules/2.6.9-023stab044.4/build/scripts/basic/split-include # << binary executable
...
... # << other binary executable
...
$ rpm -qlp ovzkernel-devel-2.6.18-8.1.3.el5.028stab033.1.x86_64.rpm | grep scripts
...
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/.bin2c.cmd
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/.conmakehash.cmd
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/.gitignore
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/.kallsyms.cmd
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/basic/docproc # << binary executable
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/basic/docproc.c
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/basic/fixdep # << binary executable
/usr/src/kernels/2.6.18-8.1.3.el5.028stab033.1-x86_64/scripts/basic/fixdep.c
...
... # << other binary executable
...
</pre>

These executables are created while building kernel package on our build system. And they are linked to libc installed on the build system! Now imagine that you've installed OpenVZ kernel package based on rhel5 kernel, say, on rhel4 distribution. The binaries mentioned above are also installed, but they can't run on this node, because other libc is installed on this system!

== Workaround ==
The clean way to solve the problem is to [http://wiki.openvz.org/Kernel_build build the kernel from sources ]. Then all binaries will be linked with the libraries that are on your node and no problems will arise.

A dirty way to get past the problem is to replace all the scripts with ones from a distribution that matches your installed system. At a minimum, you will probably need to replace the files in these directories:

/usr/src/kernels/2.6.18-8.el5.028stab031.1-x86_64/scripts/genksyms
/usr/src/kernels/2.6.18-8.el5.028stab031.1-x86_64/scripts/basic
/usr/src/kernels/2.6.18-8.el5.028stab031.1-x86_64/scripts/mod

== Externals link ==
Appropriate bug report: http://bugzilla.openvz.org/show_bug.cgi?id=586

[[Category:HOWTO]]
[[Category:Troubleshooting]]

Timezone

2007-02-17T00:22:25Z

Mh720:

Time difference between Hardware Node and VPS

During the distribution (redhat/centos) installer, you choose the timezone for your HN. The VE template has its own preconfigured timezone. So, its very possible for the zones to differ.

To resolve the problem, You should configure your VE to have the same timezone as the HN. For example, if EST is your preferred timezone:

<pre>rm -rf /etc/localtime 2>/dev/null; unlink /etc/localtime 2>/dev/null
ln -s /usr/share/zoneinfo/EST /etc/localtime
vzctl exec 1041 rm -rf /etc/localtime 2>/dev/null
vzctl exec 1041 unlink /etc/localtime 2>/dev/null
vzctl exec 1041 ln -s /usr/share/zoneinfo/EST /etc/localtime</pre>

You can find many more exciting timezones with:

find /usr/share/zoneinfo/ | more

Or, here is a shell script that will let you change the timezones in ALL of your VPS's:

<pre>#! /bin/bash
for f in `ls /vz/private`
do
vzctl exec $f rm -rf /etc/localtime 2>/dev/null
vzctl exec $f unlink /etc/localtime 2>/dev/null
vzctl exec $f ln -s /usr/share/zoneinfo/CST6CDT /etc/localtime
done</pre>

[[Category:HOWTO]]

Timezone

2007-02-17T00:21:11Z

Mh720:

Timezone

2007-02-17T00:20:04Z

Mh720: New page: Time difference between Hardware Node and VPS During the distribution (redhat/centos) installer, you choose the timezone for your HN. The VE template has its own preconfigured timezone. S...

Time difference between Hardware Node and VPS

During the distribution (redhat/centos) installer, you choose the timezone for your HN. The VE template has its own preconfigured timezone. So, its very possible for the zones to differ.

To resolve the problem, You should configure your VE to have the same timezone as the HN. For example, if EST is your preferred timezone:

rm -rf /etc/localtime 2>/dev/null; unlink /etc/localtime 2>/dev/null
ln -s /usr/share/zoneinfo/EST /etc/localtime
vzctl exec 1041 rm -rf /etc/localtime 2>/dev/null
vzctl exec 1041 unlink /etc/localtime 2>/dev/null
vzctl exec 1041 ln -s /usr/share/zoneinfo/EST /etc/localtime

You can find many more exciting timezones with:

find /usr/share/zoneinfo/ | more

Or, here is a shell script that will let you change the timezones in ALL of your VPS's:

#! /bin/bash
for f in `ls /vz/private`
do
vzctl exec $f rm -rf /etc/localtime 2>/dev/null
vzctl exec $f unlink /etc/localtime 2>/dev/null
vzctl exec $f ln -s /usr/share/zoneinfo/CST6CDT /etc/localtime
done

Talk:Monitoring openvz resources using nagios and snmp

2006-11-13T22:07:45Z

Mh720:

Very cool, thanks for the nagios plugin!

-mike

Different kernel flavors (UP, SMP, ENTERPRISE, ENTNOSPLIT)

2006-10-03T17:37:25Z

Mh720:

OpenVZ project releases several different precompiled kernels for each version. Which kernel to choose depends on what hardware do you have. The table below describes the cases when it is better to use each of these kernels.

{| class="wikitable"
|+'''Kernel flavors list'''
! Kernel type !! Description !! Hardware !! Use case
|-
! UP
| uniprocessor
| up to 4GB of RAM
|
|-
! SMP
| symmetric multiprocessor
| up to 4 GB of RAM
| 10-20 VPSs
|-
! entnosplit
| SMP + PAE support
| up to 64 GB of RAM
| 10-30 VPSs
|-
! enterprise
| SMP + PAE support + 4/4GB split
| up to 64 GB of RAM
| >20-30 VPSs
|}

These kernels are optimized for these types of hardware configurations and usage scenarios,
so choosing the right kernel can help to boost performance by about 5 to 15 per cent.

{{Note|Use <tt>rpm -ihv</tt> command for ovzkernel RPM installation. Please do not use the <tt>rpm -Uhv</tt> command to install the kernel, otherwise all the previously installed kernels may be removed from your system.}}

{{Note|When using a 64-bit processor and operating system, you need only select the SMP or non-SMP version. 64-bit linux can access the entire 64Gb of ram in ZONE_NORMAL (low memory). PAE and 4GB/4GB splitting are only needed for 32-bit OS, and so are not necessary and are disabled by default in 64-bit kernels.}}

[[Category: Kernel]]
[[Category: Need Categorization]]