OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Debian template creation

2008-12-12T07:31:32Z

Elronxenu: Use http.us.debian.org consistently

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0). (see also <tt>/usr/share/doc/vzctl/README.Debian</tt> in the ''vzctl'' Debian package)

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://http.us.debian.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For Fedora (at least Fedora 8 have it, not sure about earlier versions):
sudo yum install debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==

You can install different releases of Debian into a VE's private directory using the debootstrap command.

The command parameters are:

debootstrap --arch ARCH NAME DIRECTORY URL

Specify your architecture instead of <tt>i386</tt> if you're using something other than i386/x86. For example, for AMD64/x86_64, use <tt>amd64</tt> or for ia64, use <tt>ia64</tt>.

We use VE ID of 777 for this example; surely it can be any other unused ID.

=== Etch (current Debian stable) ===

debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/

=== Sarge (old release) ===

debootstrap sarge /vz/private/777 http://http.us.debian.org/debian

=== Woody (very old release) ===

debootstrap woody /vz/private/777 http://archive.debian.org/

== Preparing and starting the VE ==

=== Setting VE config ===
First, we need a config for the [[VE]]:
sudo vzctl set 777 --applyconfig vps.basic --save

=== Setting VE OSTEMPLATE ===
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.

sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'

=== Setting VE IP address ===
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:
sudo vzctl set 777 --ipadd x.x.x.x --save

{{Note|if you use private IP for the VE, you have to set up NAT as described in [[Using NAT for VE with private IPs]].}}

=== Setting DNS server for VE ===
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:
sudo vzctl set 777 --nameserver x.x.x.x --save

=== Starting VE ===
Now start the VE:
sudo vzctl start 777

== Customizing the installation ==
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. All those things are done inside the VE, so first command is:
sudo vzctl enter 777
export PATH=/sbin:/usr/sbin:/bin:/usr/bin

{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://http.us.debian.org/debian etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Get new security updates ===
apt-get update
apt-get upgrade

=== Install some more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login ===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
<pre>sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf</pre>

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge modutils ppp pppoeconf pppoe pppconfig

=== Disable services ===
Do not start some services, stick to bare minimum:
update-rc.d -f klogd remove
update-rc.d -f quotarpc remove
update-rc.d -f exim4 remove
update-rc.d -f inetd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.


<source lang="bash">
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys
</source>

=== Clean packages ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==

We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:
sudo vzctl set 777 --ipdel all --save

Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':
sudo nano /vz/private/777/etc/resolv.conf

Stop the VE:
sudo vzctl stop 777

Go to the VE directory:
cd /vz/private/777

Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).
sudo tar -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .

Look at the resulting tarball to see its size is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz

== Checking if template cache works ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

Finally, let's remove the VE we used for OS template cache creation:
sudo vzctl destroy 777
sudo rm /etc/vz/conf/777.conf.destroyed

[[Category: HOWTO]]
[[Category: Templates]]
[[Category: Debian]]

Debian template creation

2008-12-12T07:29:30Z

Elronxenu: Change to http.us.debian.org

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0). (see also <tt>/usr/share/doc/vzctl/README.Debian</tt> in the ''vzctl'' Debian package)

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For Fedora (at least Fedora 8 have it, not sure about earlier versions):
sudo yum install debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==

You can install different releases of Debian into a VE's private directory using the debootstrap command.

The command parameters are:

debootstrap --arch ARCH NAME DIRECTORY URL

Specify your architecture instead of <tt>i386</tt> if you're using something other than i386/x86. For example, for AMD64/x86_64, use <tt>amd64</tt> or for ia64, use <tt>ia64</tt>.

We use VE ID of 777 for this example; surely it can be any other unused ID.

=== Etch (current Debian stable) ===

debootstrap --arch i386 etch /vz/private/777 http://debian.osuosl.org/debian/

=== Sarge (old release) ===

debootstrap sarge /vz/private/777 http://http.us.debian.org/debian

=== Woody (very old release) ===

debootstrap woody /vz/private/777 http://archive.debian.org/

== Preparing and starting the VE ==

=== Setting VE config ===
First, we need a config for the [[VE]]:
sudo vzctl set 777 --applyconfig vps.basic --save

=== Setting VE OSTEMPLATE ===
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.

sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'

=== Setting VE IP address ===
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:
sudo vzctl set 777 --ipadd x.x.x.x --save

{{Note|if you use private IP for the VE, you have to set up NAT as described in [[Using NAT for VE with private IPs]].}}

=== Setting DNS server for VE ===
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:
sudo vzctl set 777 --nameserver x.x.x.x --save

=== Starting VE ===
Now start the VE:
sudo vzctl start 777

== Customizing the installation ==
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. All those things are done inside the VE, so first command is:
sudo vzctl enter 777
export PATH=/sbin:/usr/sbin:/bin:/usr/bin

{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://http.us.debian.org/debian etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Get new security updates ===
apt-get update
apt-get upgrade

=== Install some more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login ===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
<pre>sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf</pre>

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge modutils ppp pppoeconf pppoe pppconfig

=== Disable services ===
Do not start some services, stick to bare minimum:
update-rc.d -f klogd remove
update-rc.d -f quotarpc remove
update-rc.d -f exim4 remove
update-rc.d -f inetd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.


<source lang="bash">
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys
</source>

=== Clean packages ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==

We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:
sudo vzctl set 777 --ipdel all --save

Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':
sudo nano /vz/private/777/etc/resolv.conf

Stop the VE:
sudo vzctl stop 777

Go to the VE directory:
cd /vz/private/777

Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).
sudo tar -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .

Look at the resulting tarball to see its size is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz

== Checking if template cache works ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

Finally, let's remove the VE we used for OS template cache creation:
sudo vzctl destroy 777
sudo rm /etc/vz/conf/777.conf.destroyed

[[Category: HOWTO]]
[[Category: Templates]]
[[Category: Debian]]

IPv6 Configuration

2008-12-12T07:09:44Z

Elronxenu: First cut at actual documentation

= Configuring IPV6 in a VE =

Assuming you want to add globally routable ipv6 addresses
to your VEs, follow these instructions.

== Preparation ==

On the HN, first make sure /etc/vz/vz.conf has IPV6="yes"
and your HN is working correctly for ipv6.

On the HN, do:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp

== Adding each VE ==

On the HN, do:

vzctl set $VEID --ipadd 2001:xxxx:xxxx::xxxx --save

To enable the HN to reply to Neighbor Solicitation requests, do:

ip -6 neigh add proxy 2001:xxxx:xxxx::xxxx dev eth0

VPN using IPsec

2007-11-16T22:48:36Z

Elronxenu: Note that the 047 version is for kernel 2.6.18

An OpenVZ VE can join an IPsec VPN - specifically the type provided by the Cisco VPN client and 'vpnc' package.

== Using the Cisco VPN client ==

The Cisco VPN client can be downloded from Cisco, if you have an account with them. It builds a kernel module.

I have not tested this, so I don't have any instructions to set it up.

[[User:Elronxenu|Elronxenu]] 19:46, 15 November 2007 (EST)

== Using the 'vpnc' package ==

The vpnc package is part of Debian.
It runs entirely in userspace. There's a daemon which communicates with a remote VPN gateway and provides a local TUN device as a network interface for the VE to use.
Here are brief instructions to get it going:

# When using kernel 2.6.18, use revision ovz028stab047 or later. Earlier revisions are unable to create a raw socket of the necessary protocol.
# Enable the TUN device within your VE. See [[VPN via the TUN/TAP device]].
# Firewall configuration: allow UDP port 500 in and out of your client. This is used for authentication setup.
# Firewall configuration: allow protocol 50 (0x32) in and out of your client. This is used for VPN data.

[[Category:Networking]]

Download/kernel/2.6.22/2.6.22-ovz005.1

2007-11-16T22:47:54Z

Elronxenu: Remove trailing cruft

{{DevelKernel}}
{{KernelInstallInfo}}
{{KernelChangeLogInfo|2.6.22|ovz005}}

== RPMS ==
{{KernelFlavorsInfo}}

=== {{x86}} ===

{{KernelDownloadTableHead}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=i686|size=18 Mb}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=i686|size=18 Mb|flavor=-debug}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=i686|size=19 Mb|flavor=-PAE}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=i686|size=19 Mb|flavor=-PAE-debug}}
{{KernelDownloadTableTail}}

=== {{x86_64}} ===

{{KernelDownloadTableHead}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=x86_64|size=19 Mb}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=x86_64|size=19 Mb|flavor=-debug}}
{{KernelDownloadTableTail}}

=== {{IA64}} ===

{{KernelDownloadTableHead}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=ia64|size=30 Mb}}
{{KernelDownloadTableTail}}

=== PPC64 ===

* RPMS will be provided in future releases.

=== SPARC ===

* SPARC support for RPM-based distributions is available in source form only.
Please download the patch below and recompile the kernel. More info about
kernel recompiling is available at [[Kernel build#Rebuilding kernel from sources]].

== Source RPM ==

{{KernelDownloadTableHead}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=src|size=44 Mb}}
{{KernelDownloadTableRow|ver=2.6.22|rel=ovz005.1|arch=nosrc|size=1.1 Mb}}
{{KernelDownloadTableRowFile|ver=2.6.22|rel=ovz005.1|file=kernel-ovz.spec|size=16 Kb}}
{{KernelDownloadTableTail}}

== Kernel patch ==

This patch is applicable to vanilla Linux 2.6.22 kernel
(available from [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.tar.bz2 kernel.org])
to form the OpenVZ kernel.

{{KernelDownloadTableHead}}
{{KernelDownloadTableRowPatch|ver=2.6.22|rel=ovz005.1|size=856 Kb}}
{{KernelDownloadTableTail}}

== Configs ==
<p>Official configs of this OpenVZ kernel
used to build binary RPMS.</p>

{{KernelDownloadTableHead}}
{{KernelDownloadTableRowConfig|ver=2.6.22|rel=ovz005.1|config=i686|size=67 Kb}}
{{KernelDownloadTableRowConfig|ver=2.6.22|rel=ovz005.1|config=i686-PAE|size=67 Kb}}
{{KernelDownloadTableRowConfig|ver=2.6.22|rel=ovz005.1|config=x86_64|size=63 Kb}}
{{KernelDownloadTableRowConfig|ver=2.6.22|rel=ovz005.1|config=ia64|size=58 Kb}}
{{KernelDownloadTableRowConfig|ver=2.6.22|rel=ovz005.1|config=ppc64|size=57 Kb}}
{{KernelDownloadTableTail}}

Updating Debian template

2007-11-16T00:51:47Z

Elronxenu: I think the common abbreviation for Hardware Node is HN, not HW. Also why does it suddenly use VE0?

This article describes how you can update an existing precreated Debian or Ubuntu template. The procedure is pretty easy.

== Creating/configuring a temporary VE ==

First, you need to create a VE based on the template you want to update. Here is an example:

[HN]# vzctl create 555 --ostemplate debian-4.0-i386-minimal

Next, you want to specify an IP address and a nameserver:
[HN]# vzctl set 555 --ipadd x.x.x.x --nameserver y.y.y.y --save

You can get the value of nameserver from your /etc/resolv.conf. Your VE should have an Internet access, so you either supply a public IP, or see [[using NAT for VE with private IPs]] for information about how to use private IP and NAT.

Finally, check that Internet is working from inside a VE:
[HN]# vzctl exec 555 ping -n 3 www.ru

== Update ==

Enter the VE:
[HN]# vzctl enter 555

Update metadata and install updates:
[VE]# apt-get update && apt-get upgrade

Cleanup:
[VE]# apt-get clean
[VE]# > /etc/resolv.conf

Clean unused log files, .bash_history etc, then exit from a VE:
[VE] # exit

Stop a VE, remove its IP:
[VE0]# vzctl stop 555
[VE0]# vzctl set 555 --ipdel all --save

== Packing a new template cache ==

Now, rename the existing template cache:
[HN]# mv /vz/template/cache/debian-4.0-i386-minimal.tar.gz{,-old}

Now create a new tarball:
[HN]# cd /vz/private/555
[HN]# tar czf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .

Clean up:
[HN]# vzctl destroy 555
[HN]# rm -f /etc/vz/conf/555.conf.destroyed

== Test new template cache ==

First, compare the sizes of the old and the new template caches:
[HN]# ls -lh /vz/template/cache/debian-4.0-i386-minimal*
-rw-r--r-- 1 root root 55M 2007-11-13 18:11 /vz/template/cache/debian-4.0-i386-minimal.tar.gz
-rw-r--r-- 1 root root 53M 2007-08-31 02:46 /vz/template/cache/debian-4.0-i386-minimal.tar.gz-old
The sizes should not differ much.

Try to create and start VE made from your new template:
[HN]# vzctl create 222 --ostemplate debian-4.0-i386-minimal
[HN]# vzctl set 222 --ipadd 10.0.0.222 --save
[HN]# vzctl start 222
[HN]# vzctl enter 222

Now execute a few basic commands to check VE is fine. Examples are: <code>ps axf</code>, <code>dpkg -l</code>, etc.

Finally, clean up the testing VE:
[HN]# vzctl stop 222
[HN]# vzctl destroy 222
[HN]# rm -f /etc/vz/conf/222.conf.destroyed

NFS server inside container

2007-11-16T00:49:08Z

Elronxenu: /* User-space NFS server */

There are two ways to setup NFS server on common [[HN]]:
use a user-space NFS server daemon or use an in-kernel implementation
of NFS server. Some peculiarities appear if you intend to run NFS server
in [[VE]].

{{Note|for information about NFS client inside VE, see [[NFS]].}}

== Kernel NFS server ==
Binary RPMs that are provided by OpenVZ community contain kernels compiled
without NFS server support. Thus you have to
[[Kernel build|recompile the kernel]] with <code>CONFIG_NFSD=m</code>. After booting in this kernel you'll be able
to use NFS server on [[HN]].
In-kernel NFS server runs kernel threads to service requests of clients.
But for security reasons kernel threads are prohibited in [[VE]]s! So you won't
be able to run NFS server inside [[VE]] without patching the kernel.

== User-space NFS server ==
Advantage of user-space NFS server is that it does not require kernel support.
Also if it crashes — there is no crash of the system: just one process dies, not the kernel!
The disadvantage of user-space NFS server is its productivity: no one can be faster than in-kernel implementation.

One well-known implementation of NFS server is "The LINUX User-Space NFS Server" by Olaf Kirch.
Some Linux distributions contain this package: Debian Sarge (<code>nfs-user-server</code>), OpenSUSE 10.0 (<code>nfs-server</code>).
For other distributions you can download sources (for example from Debian repository) and compile it.
There is a small trick you have to know about running <code>mountd</code> and <code>nfsd</code> (these two daemons and <code>portmap</code> constitute a user-space server). You should run them with the <code>-r</code> option:
<pre>
# portmap
# rpc.mountd -r
# rpc.nfsd -r
</pre>
The reason is that these daemons check the major number of the device where the directory to export resides.
If major equals 0 then daemons assume that it is NFS and don't want to re-export it. Symptoms are
that clients will always get a "permission denied" error. Simfs (the file system on which VE is located)
is associated with so called unnamed device, in which major equals 0. So, to prevent daemons from checking for
re-exporting — just use this <code>-r</code> option.

“The LINUX User-Space NFS Server” by Olaf Kirch implements NFSv2. It means that only files with sizes less
than 2GB are processed. If you intend to use such big files then you should use another user-space NFS server
implementation: [http://unfs3.sourceforge.net/ unfs3]. It implements v3 of NFS protocol standard.

Please note that the user-space NFS server does not provide locking, or at least I couldn't get locking to work - [[User:Elronxenu|Elronxenu]] 19:49, 15 November 2007 (EST)

== External links ==
* [http://nfs.sourceforge.net/ Linux NFS Overview, FAQ and HOWTO Documents]
* [http://www.tldp.org/LDP/nag/nag.html The Network Administrators' Guide by Olaf Kirch]
* [http://unfs3.sourceforge.net/ unfs3 homepage]
* [http://packages.qa.debian.org/n/nfs-user-server.html Overview of nfs-user-server source package]

[[Category: HOWTO]]
[[Category: Networking]]

VPN using IPsec

2007-11-16T00:46:25Z

Elronxenu: How to get vpnc working

An OpenVZ VE can join an IPsec VPN - specifically the type provided by the Cisco VPN client and 'vpnc' package.

== Using the Cisco VPN client ==

The Cisco VPN client can be downloded from Cisco, if you have an account with them. It builds a kernel module.

I have not tested this, so I don't have any instructions to set it up.

[[User:Elronxenu|Elronxenu]] 19:46, 15 November 2007 (EST)

== Using the 'vpnc' package ==

The vpnc package is part of Debian.
It runs entirely in userspace. There's a daemon which communicates with a remote VPN gateway and provides a local TUN device as a network interface for the VE to use.
Here are brief instructions to get it going:

# Use revision ovz028stab047 or later. Earlier revisions are unable to create a raw socket of the necessary protocol.
# Enable the TUN device within your VE. See [[VPN via the TUN/TAP device]].
# Firewall configuration: allow UDP port 500 in and out of your client. This is used for authentication setup.
# Firewall configuration: allow protocol 50 (0x32) in and out of your client. This is used for VPN data.

[[Category:Networking]]

Kernel Build Problems

2007-11-16T00:36:40Z

Elronxenu: Add to Troubleshooting category

== Problem: OpenVZ 2.6.18 + patch-ovz028stab047.1 fails to build ==

Building a 2.6.18 kernel with patch-ovz028stab047.1 fails in Stage 2 with an error related to grsecurity.

=== Solution ===

Make the following 1-line patch to grsecurity/grsec_disabled.c, configure the kernel to disable grsecurity and build the kernel again.

--- ./grsecurity/grsec_disabled.c.ve9999 2007-10-29 20:51:17.000000000 +0300
+++ ./grsecurity/grsec_disabled.c 2007-11-02 15:20:00.000000000 +0300
@@ -1,5 +1,6 @@
#include <linux/kernel.h>
#include <linux/sched.h>
+#include <linux/module.h>

void
gr_copy_label(struct task_struct *tsk)

I believe this problem is solved in the 049 version of the patch.

[[Category: Troubleshooting]]

Kernel Build Problems

2007-11-16T00:29:38Z

Elronxenu: Solving kernel build problems

Testimonials

2007-11-15T02:36:26Z

Elronxenu: Add my imprimatur to OpenVZ

'''Following are some comments we've received from OpenVZ users.'''

----

I'm curious. For the past few months, people@openvz.org have discovered
(and fixed) an ongoing stream of obscure but serious and quite
long-standing bugs.

How are you discovering these bugs?

''Andrew Morton, [http://openvz.org/pipermail/devel/2007-July/006281.html Devel mainling list]''

----

I just wanted to congratulate you and the rest of the OpenVZ team for your
excellent, excellent work. We are now have an OpenVZ subject in our 120
hours Total Linux course here at the Bluepoint Foundation, and our
students really appreciate the work you've done. I'm learning a lot from
lurking in the devel list too. Thanks again and keep 'em coming! :D

''Engels Antonio, [http://bluepoint.com.ph/ Bluepoint Foundation]''

----

I would say, OpenVZ is '''United States of Linux''' because i can run all my lovely different type of GNU/Linux distributions(States) on '''one single machine''' with '''one kernel''' model. As stable as guaranteed for production server and handy for software development (well no more dual, tri, quad boot partition). After all, it is just a good quality software piece for Linux User. Again, welcome to '''United States of Linux''' world!!

''Victor, System Admin, [http://www.kholix.com kholix.com]''

----

Thanks for producing OpenVZ, we use it ourselves at PlanetMirror and
find that it's fantastic.

''Robert McLeay, PlanetMirror.com stuff''

----

OpenVZ is about the greatest thing we've ever found, and we're SO glad for it.

''Gregor Mosheh, HostGIS'' [https://openvz.org/pipermail/users/2007-August/001104.html]

----

OpenVZ has me seriously impressed, I was looking to try virtualisation technology and got OpenVZ up and running in only 3 trips to the coffee machine! ''-barf''

----

Hello all, just downloaded and installed OpenVZ, and i must say its a big improvement over other VPS systems that i have tested IMHO.
[http://forum.openvz.org/index.php?t=tree&goto=646&#msg_646]

----

Virtuozzo and openvz are wonderful - I don't know why more people aren't
using them. I hear a lot of hype for xen and usermode but
virtuozzo/openvz is so great for many common needs.
[http://forum.openvz.org/index.php?t=rview&goto=650#msg_650]

----

For my needs, OpenVZ is better than Xen. The one-kernel approach conserves memory, leaving more for applications. And having all VPS in one disk partition saves disk space. A surprise bonus was the template cache management with yum. The ease of keeping templates updated and quickly installing new operating environments is yummy!
[http://forum.openvz.org/index.php?t=rview&goto=3119#msg_3119]

----

Last week when we were in limbo about what to do, it was decided to try out XEN Virtualization. From what is written in the press the Xen system has alot of promise, Features such as opensource with live migration and backups sounds great; but was far too complicated to get working in our configuration. OpenVZ was the only virtual server system that was simple to install and get working.
[http://forum.openvz.org/index.php?t=msg&goto=568#msg_568]

----

It still amazes me how well OpenVZ works.
[http://forum.openvz.org/index.php?t=msg&th=368&#msg_2086]

----

[03:30:15] <pookey> well, I've been using openvz for all of about an hour, and I'm pretty impressed so far :)<br/>
''from #openvz IRC channel''

----

I am playing around for years with all major virtualization environments like all VMware products, Microsoft and several xen based solutions. But OpenVZ is the overall winner. [http://blog.openvz.org/14313.html]

----

I messed around with VMWare and Xen. I found VMWare to be somewhat over kill and Xen was damned hard to get working. The user community on the Xen mailing list is rather hostile. It looked like A number of people hang out there for the sole purpose of flaming the clueless.

I've found the OpenVZ folks to be very helpful and knowledgeable. OpenVZ is simple to install and get running. It pretty much satisfies my needs. [http://blog.openvz.org/14313.html?thread=17897#t17897]

----

I'm a sysadm and have always used xen/qemu/virtualbox/vmware server for my VMs and my customer's ones. Yesterday I decided to give OpenVZ a try and... I'm amazed. It's fast, easy and reliable.Live migration works like a charm and the use of rsync assures low data transfers. Great. [http://forum.openvz.org/index.php?t=tree&goto=14724&#msg_14724]

----

OpenVZ is one of the few pieces of software that I truly love. It works wonderfully. It should become part of the mainline kernel. ''Nick Andrew [http://www.nick-andrew.net/]''

Grsecurity

2007-11-07T22:35:00Z

Elronxenu: typo

There is a huge demand from people for support of grsecurity on OpenVZ.
However, unfortunately, grsecurity patch doesn't work as is (nor even applies) with OpenVZ kernel.
There were some efforts of supporting grsec in [http://bugzilla.openvz.org/show_bug.cgi?id=601 bug #607], but
failed and the grsecurity patch was never stable with OpenVZ.

So instead OpenVZ team selected another approach. We port the features of grsecurity most requested by users and add them, maintain,
document and support.

== TPE (Trusted Path Execution) ==

Starting from 2.6.18-028stab047.1 stable kernels OpenVZ kernels support TPE grsecurity feature out of the box.
Which means root user can configure TPE inside VE as usually accessing the following /proc files:
* /proc/sys/kernel/grsecurity/grsec_lock
* /proc/sys/kernel/grsecurity/tpe
* /proc/sys/kernel/grsecurity/tpe_gid
* /proc/sys/kernel/grsecurity/tpe_restrict_all

To enable TPE feature standard way just type:
# echo <GID> > /proc/sys/kernel/grsecurity/tpe_gid
# echo 1 > /proc/sys/kernel/grsecurity/tpe
' lock grsecurity settings
# echo 1 > /proc/sys/kernel/grsecurity/grsec_lock

Debian template creation

2007-11-07T14:51:52Z

Elronxenu: Add note for woody and its location

These are rough instructions of how to manually create basic Debian Etch (4.0) template cache, which can be used to create OpenVZ [[VE]]s based on Debian Etch (4.0).

'''Notes:'''
* You shouldn't be running as root, but as a user that is permitted to use sudo instead. It's a dangerous idea, run as root at your peril.
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.
* Anywhere you see <tt>http://debian.osuosl.org/debian/</tt>, you can substitute your favorite Debian mirror. ([http://www.debian.org/mirror/list List of official Debian Mirrors])

== Prerequisites ==
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.

For Debian:
sudo apt-get install debootstrap

For Gentoo:
sudo emerge debootstrap

For other distros you might need to install it from sources, or search for an appropriate package for your distribution. An RPM is available on the [http://forum.openvz.org/index.php?t=tree&th=142&mid=584 OpenVZ Forum].

== Bootstrapping Debian ==

You can install different releases of Debian into a VE's private directory using the debootstrap command.

The command parameters are:

debootstrap --arch ARCH NAME DIRECTORY URL

Specify your architecture instead of <tt>i386</tt> if you're using something other than i386/x86. For example, for AMD64/x86_64, use <tt>amd64</tt> or for ia64, use <tt>ia64</tt>.

We use VE ID of 777 for this example; surely it can be any other unused ID.

=== Etch (current Debian stable) ===

debootstrap --arch i386 etch /vz/private/777 http://debian.osuosl.org/debian/

=== Sarge (old release) ===

debootstrap sarge /vz/private/777 http://http.us.debian.org/debian

=== Woody (very old release) ===

debootstrap woody /vz/private/777 http://archive.debian.org/

== Preparing and starting the VE ==

=== Setting VE config ===
First, we need a config for the [[VE]]:
sudo vzctl set 777 --applyconfig vps.basic --save

=== Setting VE OSTEMPLATE ===
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.

sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'

=== Setting VE IP address ===
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:
sudo vzctl set 777 --ipadd x.x.x.x --save

{{Note|if you use private IP for the VE, you have to set up NAT as described in [[Using NAT for VE with private IPs]].}}

=== Setting DNS server for VE ===
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:
sudo vzctl set 777 --nameserver x.x.x.x --save

=== Starting VE ===
Now start the VE:
sudo vzctl start 777

== Customizing the installation ==
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. All those things are done inside the VE, so first command is:
sudo vzctl enter 777
export PATH=/sbin:/usr/sbin:/bin:/usr/bin

{{Note|'''Warning!''' Do not run the commands below on the hardware node, they are only to be run within the VE!}}

=== Set Debian repositories ===
cat <<EOF > /etc/apt/sources.list
deb http://debian.osuosl.org/debian/ etch main contrib
deb http://security.debian.org etch/updates main contrib
EOF

=== Get new security updates ===
apt-get update
apt-get upgrade

=== Install some more packages ===
Installing packages could be an interactive process so the system might ask some questions. You can install more packages if you'd like. For example:
apt-get install ssh quota

=== Set sane permissions for <tt>/root</tt> directory ===
chmod 700 /root

=== Disable root login ===
This will disable root login by default.
usermod -L root

=== Disable getty ===
Disable running <tt>getty</tt>s on terminals as a VE does not have any:
sed -i -e '/getty/d' /etc/inittab

=== Disable <tt>sync()</tt> for syslog ===
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:
<pre>sed -i -e 's@$[[:space:]]$$/var/log/$@\1-\2@' /etc/syslog.conf</pre>

=== Fix <tt>/etc/mtab</tt> ===
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:
rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

=== Remove some unneeded packages ===
If you have any packages you'd like to remove, now's the time for it. Here's an example:
dpkg --purge modutils ppp pppoeconf pppoe pppconfig

=== Disable services ===
Do not start some services, stick to bare minimum:
update-rc.d -f klogd remove
update-rc.d -f quotarpc remove
update-rc.d -f exim4 remove
update-rc.d -f inetd remove

=== Fix SSH host keys ===
This is only useful if you installed SSH. Each individual [[VE]] should have its own pair of SSH host keys. The code below will wipe out the existing SSH keys and instruct the newly-created [[VE]] to create new SSH keys on first boot.


<pre>
rm -f /etc/ssh/ssh_host_*
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys
#!/bin/bash
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''
rm -f \$0
EOF
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys
</pre>

=== Clean packages ===
After installing packages, you'll have some junk packages laying around in your cache. Since you don't want your template to have those, this command will wipe them out.
apt-get clean

Now everything is done. Exit from the template and go back to the hardware node.
exit

== Preparing for and packing template cache ==

We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:
sudo vzctl set 777 --ipdel all --save

Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':
sudo nano /vz/private/777/etc/resolv.conf

Stop the VE:
sudo vzctl stop 777

Go to the VE directory:
cd /vz/private/777

Now create a cached OS tarball. In the command below, you'll want to replace <tt>i386</tt> with your architecture (i386, amd64, ia64, etc).
sudo tar -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .

Look at the resulting tarball to see its size is sane:
# ls -lh /vz/template/cache
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz

== Checking if template cache works ==
We can now create a VE based on the just-created template cache. Be sure to change <tt>i386</tt> to your architecture just like you did when you named the tarball above.
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal

Now make sure that it works:
sudo vzctl start 123456
sudo vzctl exec 123456 ps ax

You should see that a few processes are running.

== Final cleanup ==
Stop and remove the test VE you just created:
sudo vzctl stop 123456
sudo vzctl destroy 123456
sudo rm /etc/vz/conf/123456.conf.destroyed

Finally, let's remove the VE we used for OS template cache creation:
sudo vzctl destroy 777
sudo rm /etc/vz/conf/777.conf.destroyed

[[Category: HOWTO]]
[[Category: Templates]]

NFS

2007-10-29T02:24:02Z

Elronxenu: Add a note about debian

This page describes how to mount NFS partition inside VE.

== NFS server ==
Currently OpenVZ kernel doesn't include kernel NFS server support. However you are still able to use user space [[NFS server inside VE]].

== NFS client ==
=== Preparations ===
==== Prerequisites ====
You will need the following software:

# [http://openvz.org/download/utils#vzctl vzctl] version 3.0.13 or higher (do <code>vzctl --version</code>)
# [http://openvz.org/download/kernel/ kernel] version 2.6.18-028test006 or higher (2.6.18-028stab* will do), or any recent RHEL5-based or 2.6.20-based kernel.

Note: In all the kernels earlier than 028stab038, kernel NFS support can be given to a VE by setting:

sunrpc.ve_allow_rpc = 1
fs.nfs.ve_allow_nfs = 1
kernel.ve_allow_kthreads = 1

This can be done by adding the above lines into /etc/sysctl.conf on the hardware node, and then running <code>sysctl -p</code>.

===== Debian Notes =====

Debian Etch still uses vzctl version 3.0.11 and so NFS client support is not yet available. Lenny presently has version 3.0.18.

==== Prepare the HN ====

For NFS mounts to work in the VEs with the RHEL5-based kernels you must enable kernel threads in the VE by setting "kernel.ve_allow_kthreads=1" in /etc/sysctl.conf

<pre>
# modprobe nfs
</pre>

==== Prepare the VE ====
To allow a VE use NFS filesystem, you will need to start it with "nfs" feature enabled. If the VE is running while you set the --features "nfs:on", you will need to reboot it.
<pre>
# vzctl set 101 --features "nfs:on" --save
# vzctl start 101
</pre>

After this you may see nfs in <code>/proc/filesystems</code>
<pre>
# vzctl exec 101 cat /proc/filesystems
ext3
ext2
nodev rpc_pipefs
nodev proc
nodev nfs
nodev sysfs
nodev tmpfs
nodev devpts
</pre>

=== Mounting NFS ===
Assuming that you already have NFS server set up at <code>192.168.0.1:/nfs_pub</code> mounting will be simple
<pre>
# vzctl enter 100
# mkdir /nfs
# mount -t nfs 192.168.0.1:/nfs_pub /nfs
# cat /proc/mounts
simfs / simfs rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw 0 0
nfs /nfs nfs rw,vers=3,rsize=32768,wsize=32768,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=192.168.0.1 0 0
</pre>

For more details on how to setup NFS mount see [http://nfs.sourceforge.net/nfs-howto/ar01s04.htm NFS-client HOWTO]

=== Known issues ===
There are quite a few parameters in NFS, so sometimes it doesn't work due to misconfiguration. We created a separate
page for discribing such situation: [[ NFS doesn't work ]]

[[Category: HOWTO]]

NFS

2007-10-29T02:15:17Z

Elronxenu: note vzctl version

This page describes how to mount NFS partition inside VE.

== NFS server ==
Currently OpenVZ kernel doesn't include kernel NFS server support. However you are still able to use user space [[NFS server inside VE]].

== NFS client ==
=== Preparations ===
==== Prerequisites ====
You will need the following software:

# [http://openvz.org/download/utils#vzctl vzctl] version 3.0.13 or higher (do <code>vzctl --version</code>)
# [http://openvz.org/download/kernel/ kernel] version 2.6.18-028test006 or higher (2.6.18-028stab* will do), or any recent RHEL5-based or 2.6.20-based kernel.

Note: In all the kernels earlier than 028stab038, kernel NFS support can be given to a VE by setting:

sunrpc.ve_allow_rpc = 1
fs.nfs.ve_allow_nfs = 1
kernel.ve_allow_kthreads = 1

This can be done by adding the above lines into /etc/sysctl.conf on the hardware node, and then running <code>sysctl -p</code>.

==== Prepare the HN ====

For NFS mounts to work in the VEs with the RHEL5-based kernels you must enable kernel threads in the VE by setting "kernel.ve_allow_kthreads=1" in /etc/sysctl.conf

<pre>
# modprobe nfs
</pre>

==== Prepare the VE ====
To allow a VE use NFS filesystem, you will need to start it with "nfs" feature enabled. If the VE is running while you set the --features "nfs:on", you will need to reboot it.
<pre>
# vzctl set 101 --features "nfs:on" --save
# vzctl start 101
</pre>

After this you may see nfs in <code>/proc/filesystems</code>
<pre>
# vzctl exec 101 cat /proc/filesystems
ext3
ext2
nodev rpc_pipefs
nodev proc
nodev nfs
nodev sysfs
nodev tmpfs
nodev devpts
</pre>

=== Mounting NFS ===
Assuming that you already have NFS server set up at <code>192.168.0.1:/nfs_pub</code> mounting will be simple
<pre>
# vzctl enter 100
# mkdir /nfs
# mount -t nfs 192.168.0.1:/nfs_pub /nfs
# cat /proc/mounts
simfs / simfs rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw 0 0
nfs /nfs nfs rw,vers=3,rsize=32768,wsize=32768,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=192.168.0.1 0 0
</pre>

For more details on how to setup NFS mount see [http://nfs.sourceforge.net/nfs-howto/ar01s04.htm NFS-client HOWTO]

=== Known issues ===
There are quite a few parameters in NFS, so sometimes it doesn't work due to misconfiguration. We created a separate
page for discribing such situation: [[ NFS doesn't work ]]

[[Category: HOWTO]]

X inside VE

2007-10-27T12:40:11Z

Elronxenu: typo

There are several ways to run X applications inside your [[VE]].

== X forwarding ==

To run an X application inside a [[VE]], one need simply to connect to a VE with '''ssh -X''':
<pre>
host# ssh -2 -c blowfish -X user@address
</pre>

After login to VE check that <code>$DISPLAY</code> variable is set and X11 forwarding is enabled:
<pre>
ve# echo $DISPLAY
localhost:10.0
</pre>

In case <code>$DISPLAY</code> is not set, make sure that X forwarding is enabled in <code>sshd</code> config inside VE. In most Linux distros sshd configuration is stored in <code>/etc/ssh/sshd_config</code>. You should set parameter <code>X11Forwarding</code> to <code>yes</code>. Also VE should contain <code>xauth</code> package, thus install <code>xauth</code> if it is missing (in Debian this is part of the xbase-clients package). After that, restart your sshd daemon:
<pre>
ve# /etc/init.d/sshd restart
</pre>

{{Note|Don't forget to reconnect after this}}

Now you can run X applications from your VE:
<pre>
ve# firefox
</pre>

Note, that if you want to run complete X window environment (including window manager), you should kill local window manager and run only pure X server. Secondly you shoud use '''-Y''' option when invoking ssh. And if you want to run gnome/kde/..., don't forget to increase [[UBC]] limits, 'cause default values are certainly too small for these monsters. ;)

== VNC for X desktop ==
First, one need to run '''Xvnc''' server inside VE. The easiest way for this is to run
'''vncserver''' script. This scripts starts all the required services
and small http daemon which provides graphical web access to your desktop (via Java applet).

<pre>
ve# vncserver -name mydesktop
New 'mydekstop' desktop is ve:1

Starting applications specified in ~/.vnc/xstartup
Log file is ~/.vnc/ve:1.log
</pre>

Now when your desktop is up and running you can connect to it
using '''vncviewer''' command:
<pre>
host# vncviewer <VE_IP>:1
</pre>

If the VNC desktop is the same size or larger than your X desktop, you will see scroll bars on the bottom and the side. This is often inconvenient. You may reduce your VNC desktop to a more reasonable size like this:
<pre>vncserver -geometry 1000x650</pre>
This setting works quite well for a 1024 by 768 X desktop setting.

=== Starting KDE desktop with VNC ===
To start KDE desktop instead of default twm one replace <code>twm &</code> line with <code>startkde &</code> in user's
<code>~/.vnc/xstartup</code> file on the VE.

=== Connecting with VNC from firewalled network ===
VNC uses 590x TCP ports for its connections. These ports can be firewalled in
many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow.
A usual '''ssh''' can be used for tunneling VNC connections as described below.

<pre>
localhost# ssh -L 5900:localhost:5900 <remote host>
</pre>

where <remote host> is the name of the system you want to connect to. When you are asked for a username and password enter your normal username and password. Then start the VNC session to localhost, i.e.

<pre>
localhost# vncviewer localhost
</pre>

== Using xdm ==
It should be also possible to do remote X by running '''xdm''' inside VE and
X -query <remote IP> :1

However VNC approach is much easier.

== External links ==
* http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal=
* http://ait.web.psi.ch/services/linux/kde-desktop-sharing.htm
* http://ait.web.psi.ch/services/ssh/vnc-ssh.html
* http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html
* http://www.linuxjournal.com/article/5499
* http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html
* http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html
* http://faq.gotomyvnc.com/fom-serve/cache/56.html

[[Category: HOWTO]]
[[Category: Networking]]

X inside VE

2007-10-27T12:39:27Z

Elronxenu: Add note about Debian

There are several ways to run X applications inside your [[VE]].

== X forwarding ==

To run an X application inside a [[VE]], one need simply to connect to a VE with '''ssh -X''':
<pre>
host# ssh -2 -c blowfish -X user@address
</pre>

After login to VE check that <code>$DISPLAY</code> variable is set and X11 forwarding is enabled:
<pre>
ve# echo $DISPLAY
localhost:10.0
</pre>

In case <code>$DISPLAY</code> is not set, make sure that X forwarding is enabled in <code>sshd</code> config inside VE. In most Linux distros sshd configuration is stored in <code>/etc/ssh/sshd_config</code>. You should set parameter <code>X11Forwarding</code> to <code>yes</code>. Also VE should contain <code>xauth</code> package, thus install <code>xauth</code> if it is missing (in Debian this is part of the xbase-clients package). After that, restart your sshd daemon:
<pre>
ve# /etc/init.d/sshd restart
</pre>

{{Note|Don't forget to reconnect after this}}

Now you can run X applications from your VE:
<pre>
ve# firefox
</pre>

Note, that if you want to run complete X window environment (including window manager), you should kill local window manager and run only pure X server. Secondly you shoud use '''-Y''' option when invoking ssh. And if you want to run gnome/kde/..., don't forget to increase [[UBC]] limits, 'cause default values are certainly too small for these monsters. ;)

== VNC for X desktop ==
First, one need to run '''Xvnc''' server inside VE. The easiest way for this is to run
'''vncserver''' script. This scripts starts all the required services
and small http daemon which provides graphical web access to your desktop (via Java applet).

<pre>
ve# vncserver -name mydesktop
New 'mydekstop' desktop is ve:1

Starting applications specified in ~/.vnc/xstartup
Log file is ~/.vnc/ve:1.log
</pre>

Now when your desktop is up and running you can connect to it
using '''vncviewer''' command:
<pre>
host# vncviewer <VE_IP>:1
</pre>

If the VNC desktop is the same size or larger than your X desktop, you will see scroll bars on the bottom and the side. This is often inconvenient. You may reduce your VNC desktop to a more reasonable size like this:
<pre>vncserver -geometry 1000x650</pre>
This setting works quite well for a 1024 by 768 X desktop setting.

=== Starting KDE desktop with VNC ===
To start KDE desktop instead of default twm one replace <code>twm &</code> line with <code>startkde &</code> in user's
<code>~/.vnc/xstartup</code> file on the VE.

=== Connecting with VNC from firewalled network ===
VNC uses 590x TCP ports for its connections. These ports can be firewalled in
many networks so in order to be able to connect to remote side one need to tunnel VNC connections somehow.
A usuall '''ssh''' can be used for tunneling VNC connections as described below.

<pre>
localhost# ssh -L 5900:localhost:5900 <remote host>
</pre>

where <remote host> is the name of the system you want to connect to. When you are asked for a username and password enter your normal username and password. Then start the VNC session to localhost, i.e.

<pre>
localhost# vncviewer localhost
</pre>

== Using xdm ==
It should be also possible to do remote X by running '''xdm''' inside VE and
X -query <remote IP> :1

However VNC approach is much easier.

== External links ==
* http://forum.openvz.org/index.php?t=tree&th=235&mid=1115&&rev=&reveal=
* http://ait.web.psi.ch/services/linux/kde-desktop-sharing.htm
* http://ait.web.psi.ch/services/ssh/vnc-ssh.html
* http://www.vnc.com/pipermail/vnc-list/2002-July/031831.html
* http://www.linuxjournal.com/article/5499
* http://www.realvnc.com/pipermail/vnc-list/2002-March/029502.html
* http://www.redhat.com/archives/rhl-list/2003-December/msg01859.html
* http://faq.gotomyvnc.com/fom-serve/cache/56.html

[[Category: HOWTO]]
[[Category: Networking]]

Mounting filesystems

2007-10-27T12:38:08Z

Elronxenu: Add it to the HOWTO list

== Mounting filesystems within a VE ==

To mount filesystems inside a VE, you have several choices:

* NFS (the VE will be an NFS Client) - see [[NFS]]
* FUSE - see [[FUSE]]
* Bind mount from Hardware Node

=== Bind mount from Hardware Node ===

Recent Linux kernels support an operation called 'bind mounting' which makes part of a mounted filesystem visible at some other mount point. See 'man bind' for more information.

Bind mounts can be used to make directories on the hardware node visible to the VE.

OpenVZ uses two directories. Assuming our VE is numbered 777, these directories are:

/var/lib/vz/private/777
/var/lib/vz/root/777

The /var/lib/vz/private directory contains root directory contents. This directory or subdirectory is often symlinked onto a different filesystem, for example:

/var/lib/vz/private -> /mnt/openvz

Putting VE root directories onto a separate filesystem (not the hardware node root filesystem) is good storage management practice. It protects the Hardware Node root filesystem from being filled up by a VE; this could cause problems on the Hardware Node.

=== Requirement ===

'''On the HN we have a directory '/home' which we wish to make available (shared) to all VEs.'''

You would think that you could bind mount this directory, as in: 'mount --bind /home /var/lib/vz/private/777/home' but this does not work - the contents of /home cannot be seen within the VE.

This is where the second directory listed above (/var/lib/vz/root/777) is used. If a VE is not started, this directory is empty. But after starting a VE, this directory contains what the VE sees as its mounted filesystems.

The correct command to issue on the HN is:

mount --bind /home /var/lib/vz/root/777/home

The VE must be started and the destination directory must exist. The VE will see this directory mounted like this:

# df
Filesystem 1K-blocks Used Available Use% Mounted on
simfs 10485760 298728 10187032 3% /
tmpfs 484712 0 484712 0% /lib/init/rw
tmpfs 484712 0 484712 0% /dev/shm
ext3 117662052 104510764 7174408 94% /home

[[Category:HOWTO]]

NFS

2007-10-27T12:33:26Z

Elronxenu: /* NFS server */

This page describes how to mount NFS partition inside VE.

== NFS server ==
Currently OpenVZ kernel doesn't include kernel NFS server support. However you are still able to use user space [[NFS server inside VE]].

== NFS client ==
=== Preparations ===
==== Prerequisites ====
You will need the following software:

# [http://openvz.org/download/utils#vzctl vzctl] version 3.0.13 or higher
# [http://openvz.org/download/kernel/ kernel] version 2.6.18-028test006 or higher (2.6.18-028stab* will do), or any recent RHEL5-based or 2.6.20-based kernel.

Note: In all the kernels earlier than 028stab038, kernel NFS support can be given to a VE by setting:

sunrpc.ve_allow_rpc = 1
fs.nfs.ve_allow_nfs = 1
kernel.ve_allow_kthreads = 1

This can be done by adding the above lines into /etc/sysctl.conf on the hardware node, and then running <code>sysctl -p</code>.

==== Prepare the HN ====

For NFS mounts to work in the VEs with the RHEL5-based kernels you must enable kernel threads in the VE by setting "kernel.ve_allow_kthreads=1" in /etc/sysctl.conf

<pre>
# modprobe nfs
</pre>

==== Prepare the VE ====
To allow a VE use NFS filesystem, you will need to start it with "nfs" feature enabled. If the VE is running while you set the --features "nfs:on", you will need to reboot it.
<pre>
# vzctl set 101 --features "nfs:on" --save
# vzctl start 101
</pre>

After this you may see nfs in <code>/proc/filesystems</code>
<pre>
# vzctl exec 101 cat /proc/filesystems
ext3
ext2
nodev rpc_pipefs
nodev proc
nodev nfs
nodev sysfs
nodev tmpfs
nodev devpts
</pre>

=== Mounting NFS ===
Assuming that you already have NFS server set up at <code>192.168.0.1:/nfs_pub</code> mounting will be simple
<pre>
# vzctl enter 100
# mkdir /nfs
# mount -t nfs 192.168.0.1:/nfs_pub /nfs
# cat /proc/mounts
simfs / simfs rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw 0 0
nfs /nfs nfs rw,vers=3,rsize=32768,wsize=32768,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=192.168.0.1 0 0
</pre>

For more details on how to setup NFS mount see [http://nfs.sourceforge.net/nfs-howto/ar01s04.htm NFS-client HOWTO]

=== Known issues ===
There are quite a few parameters in NFS, so sometimes it doesn't work due to misconfiguration. We created a separate
page for discribing such situation: [[ NFS doesn't work ]]

[[Category: HOWTO]]

Mounting filesystems

2007-10-27T12:32:45Z

Elronxenu: Describe how to mount filesystems from the host into the VE

Physical to container

2007-10-27T12:01:32Z

Elronxenu: Various language and typo cleanups

A rough description of how to migrate existing physical server into a [[VE]].

== Prepare a new “empty” VE ==
For OpenVZ this would mean the following (assume you chose VE ID of 123):

mkdir /vz/root/123 /vz/private/123
cat /etc/vz/conf/ve-vps.basic.conf-sample > /etc/vz/conf/123.conf

== Preparing to migrate ==

Stop most services on a machine to be migrated. “Most” means services such as web server, databases and the like — so you will not lose your data. Just leave the bare minimum (including ssh daemon).

== Copying the data ==

Copy all your data from the machine to an OpenVZ box. Say you'll be using VE with ID of 123, then all the data should be placed to <code>/vz/private/123/</code> directory (so there will be directories such as <code>/vz/private/123/bin</code>, <code>etc</code>, <code>var</code> and so on). This could be done in several ways:

=== rsync ===
rsync example (run from the new HN):
rsync -arvpz --numeric-ids --exclude dev --exclude proc --exclude tmp -e "ssh -l root@a.b.c.d" root@a.b.c.d:/ /vz/private/123/

'''Advantage:''' Your system doesn't really go down.

=== Live CD ===
Another way to do is using a live cd, booting up and use tar to dump the complete disk in a tar you save over the network or on a USB device.

=== Tar ===
Another approach is using tar and excluding some dirs, you could do it like this:

Create a file /tmp/excludes.excl with these contents:
.bash_history
/dev/*
/mnt/*
/tmp/*
/proc/*
/sys/*
/usr/src/*

Then create the tar. But remember, when the system is 'not' using udev, you have to look into /proc/ after creating your VE because some devices might not exist. (/dev/ptmx or others)

# tar cjpf /tmp/mysystem.tar.bz2 / -X /tmp/excludes.excl

Naturally, you can only do this when the critical services (MySQL, apache, ..) are stopped and your /tmp filesystem is big enough to contain your tar.

'''Advantage:''' You don't need to boot from a live cd, so your system doesn't really go down.

== Setting VE parameters ==

=== OSTEMPLATE ===
You have to add <code>OSTEMPLATE=xxx</code> line to <code>/etc/vz/conf/123.conf</code> file, where <code>xxx</code> would be distribution name (like <code>debian-3.0</code>) for vzctl to be able to make changes specific for this distribution.

=== IP address(es) ===
Also, you have to supply an IP for a new VE:

vzctl set 123 --ipadd x.x.x.x --save

=== venet vs. veth ===
You may use veth interface instead of venet if you need just bring old server up for seamless migration of services.
It may be nessessary if server you are migrating is badly configured and it is hard to find all hard-coded net interfaces settings and so on.

veth inteface may be included into bridge to allow seamless old installation access.

== Making adjustments ==
Since VE is a bit different to a real physical server, you have to edit some files inside your new VE.

=== /etc/inittab ===
A VE does not have real ttys, so you have to disable getty in <code>/etc/inittab</code> (i. e. <code>/vz/private/123/etc/inittab</code>).

sed -i -e '/getty/d' /vz/private/123/etc/inittab

=== /etc/mtab ===
Link <code>/etc/mtab</code> to <code>/proc/mounts</code>, for <code>df</code> to work properly:

rm -f /vz/private/123/etc/mtab
ln -s /proc/mounts /vz/private/123/etc/mtab

{{out|The problem here is VE's root filesystem (<code>/</code>) is mounted not from the VE itself, but rather from the host system. That leaves <code>/etc/mtab</code> in VE without a record for <code>/</code> being mounted, thus df doesn't show it. By linking <code>/etc/mtab → /proc/mounts</code> we make sure /etc/mtab shows what is really mounted in a VE.

Sure this is not the only way to fix df; you can just manually add a line to <code>/etc/mtab</code> telling <code>/</code> is mounted, and make sure this line will be there after a reboot.}}

=== /etc/fstab ===
Since you do not have any real disk partitions in a VE, /etc/fstab (or most part of it) is no longer needed. Empty it (excluding the line for /dev/pts):

cp /vz/private/123/etc/fstab /vz/private/123/etc/fstab.old
grep devpts /vz/private/123/etc/fstab.old > /vz/private/123/etc/fstab

You can also mount a devpts in a running (but not fully functional) VE:
vzctl exec 123 mount -t devpts none /dev/pts

=== /dev ===

==== Introduction: static /dev ====
In order for VE to work, some nodes should be present in VE's /dev. For modern distributions, udev is taking care of it. For a variety of reasons udev doesn't make much sense in a VE, so the best thing to do is to disable udev and create needed device nodes manually.

Note that in some distributions <code>/dev</code> is mounted on tmpfs — this will not work in case of static /dev. So what you need to do is find out where <code>/dev</code> is being mounted on tmpfs and remove this. This is highly distribution-dependent; please add info for your distro here.

After you made sure your /dev is static, populate it with needed device nodes.

==== tty device nodes ====

In order for vzctl enter to work, a VE needs to have some entries in /dev. This can either be /dev/ttyp* and /dev/ptyp*, or /dev/ptmx and mounted /dev/pts.

===== /dev/ptmx =====
Check that /dev/ptmx exists. If it does not, create with:
mknod /vz/private/123/dev/ptmx c 5 2

===== /dev/pts/ =====
Check that /dev/pts exists. It's a directory, if it does not exist, create with:
mkdir /vz/private/123/dev/pts

===== /dev/ttyp* and /dev/ptyp* =====
Check that /dev/ttyp* and /dev/ptyp* files are there. If not, you have to create those, either by using /sbin/MAKEDEV, or by copying them from the host system.

To copy:
cp -a /dev/ttyp* /dev/ptyp* /vz/private/123/dev/

To recreate with MAKEDEV, either
/sbin/MAKEDEV -d /vz/private/123/dev ttyp ptyp
or
cd /vz/private/123/dev && /sbin/MAKEDEV ttyp

====/dev/null====
Make sure sure /dev/null is not a file or directory; if unsure remove and recreate. If this is not correct sshd will not start correctly.
rm -f /vz/private/123/dev/null
mknod /vz/private/123/dev/null c 1 3

==== /dev/urandom ====
Check that /dev/urandom exists. If it does not, create with:
mknod /vz/private/123/dev/urandom c 1 9

===/proc===
Make sure the /proc directory exists:
ls -la /vz/private/123/ | grep proc

If it doesn't, create it:
mkdir /vz/private/123/proc

=== /etc/init.d services ===

Some system services can (or in some cases should) be disabled. A few good candidates are:

* acpid, amd (not needed)
* checkfs, checkroot (no filesystem checking is required in VE)
* clock (no clock setting is required/allowed in VE)
* consolefont (VE does not have a console)
* hdparm (VE does not have real hard drives)
* klogd (unless you use iptables to LOG some packets)
* keymaps (VE does not have a real keyboard)
* kudzu (VE does not have real hardware)
* lm_sensors (VE does not have access to hardware sensors)
* microcodectl (VE can not update CPU microcode)
* netplugd (VE does not have real Ethernet device)

To see which services are enabled:
* RedHat/Fedora/SUSE: <code>/sbin/chkconfig --list</code>
* Debian: Use '<code>rcconf</code>' (ncurses) or <code>update-rc.d</code>
( See: http://www.debianadmin.com/manage-linux-init-or-startup-scripts.html )
* Gentoo: <code>/sbin/rc-update show</code>

To disable the service:
* RedHat/Fedora/SUSE: <code>/sbin/chkconfig --del SERVICENAME </code>
* Debian: <code>' update-rc.d -f hdparm remove '</code>
* Gentoo: <code>/sbin/rc-update del SERVICENAME</code>

=== Disable old network interface ===
You should disable your old physical network interface from starting at boot time. This is distribution-dependant.

==== Fedora/CentOS/Red Hat ====
Edit /vz/private/{VEID}/etc/sysconfig/network-scripts/ifcfg-eth''x''

Make the following look like this:
ONBOOT=no

==== Debian/Ubuntu ====
Edit /etc/network/interfaces

<pre>
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
# automatically added when upgrading
auto lo eth0
iface lo inet loopback

iface eth0 inet dhcp
address 10.0.0.4
netmask 255.0.0.0
network 10.0.0.0
broadcast 10.0.0.255
</pre>

You can either comment out the eth* interface stanza(s), or take it out of the "auto" line(s).

==== openSUSE/SLES ====

Use Yast.

=== Other adjustments ===
There might be other adjustments needed. Please add those here (just above this section) if you have more info.

== Starting a new VE ==

Try to start your new VE:

vzctl start 123

Now check that everything works fine. If not, see [[#Troubleshooting]] below.

== Troubleshooting ==

=== Can't enter VE ===

If you can not enter your VE (using <code>vzctl enter</code>), you should be able to at least execute commands in it.

First, see the [[#tty device nodes]] section above.

Next, check if devpts is mounted:
vzctl exec 123 mount | grep pts

If it is not mounted, mount it:
vzctl exec 123 mount -t devpts none /dev/pts

Then, add the appropriate mount command to VE's startup scripts. On some distros, you need to have the appropriate line in VE's /etc/fstab.

In Fedora, try commenting out any '''udev''' entries in /vz/private/{VEID}/etc/rc.sysinit
vi /vz/private/{VEID}/etc/rc.sysinit
Locate the '''udev''' entry from within vim
/udev
Then comment the line similar to this:
#[ -x /sbin/start_udev ] && /sbin/start_udev

=== Other problems ===
If anything goes wrong, try to find out why and fix. If you have enough Linux experience, it can be handled. Also check out IRC and please report back on this page.

== Success Stories ==
- Debian 3.1 Sarge with MySQL, apache2, PowerDNS
--[[User:Stoffell|stoffell]] 08:41, 8 February 2007 (EST)

- Red Hat 7.2 with MySQL 3.23, apache, Chilisoft --[[User:Stoffell|stoffell]] 13:26, 9 February 2007 (EST)

- Gentoo with Courier, Postfix, MySQL, Apache2
--[[User:bfrackie|bfrackie]] 19:00, 18 March 2007 (EST)

- AltLinux Master with qmail, MySQL, Apache, etc - to Debian/testing with OpenVZ --[[User:alexkuklin|alexkuklin]]

[[Category:HOWTO]]

Physical to container

2007-10-27T11:53:44Z

Elronxenu: typo

A rough description of how to migrate existing physical server into a [[VE]].

== Prepare a new “empty” VE ==
For OpenVZ this would mean the following (assume you chose VE ID of 123):

mkdir /vz/root/123 /vz/private/123
cat /etc/vz/conf/ve-vps.basic.conf-sample > /etc/vz/conf/123.conf

== Preparing to migrate ==

Stop most services on a machine to be migrated. “Most” means services such as web server, databases and the like — so you will not lose your data. Just leave the bare minimum (including ssh daemon).

== Copying the data ==

Copy all your data from the machine to an OpenVZ box. Say you'll be using VE with ID of 123, then all the data should be placed to <code>/vz/private/123/</code> directory (so there will be directories such as <code>/vz/private/123/bin</code>, <code>etc</code>, <code>var</code> and so on). This could be done in several ways:

=== rsync ===
rsync example (run from the new HN):
rsync -arvpz --numeric-ids --exclude dev --exclude proc --exclude tmp -e "ssh -l root@a.b.c.d" root@a.b.c.d:/ /vz/private/123/

'''Advantage:''' Your system doesn't really go down.

=== Live CD ===
Another way to do is using a live cd, booting up and use tar to dump the complete disk in a tar you save over the network or on a USB device.

=== Tar ===
Another approach is using tar and excluding some dirs, you could do it like this:

Create a file /tmp/excludes.excl with these contents:
.bash_history
/dev/*
/mnt/*
/tmp/*
/proc/*
/sys/*
/usr/src/*

Then create the tar. But remember, when the system is 'not' using udev, you have to look into /proc/ after creating your VE because some devices might not exist. (/dev/ptmx or others)

# tar cjpf /tmp/mysystem.tar.bz2 / -X /tmp/excludes.excl

Naturally, you can only do this when the critical services (MySQL, apache, ..) are stopped and your /tmp filesystem is big enough to contain your tar.

'''Advantage:''' You don't need to boot from a livecd, so your system doesn't really go down.

== Setting VE parameters ==

=== OSTEMPLATE ===
You have to add <code>OSTEMPLATE=xxx</code> line to <code>/etc/vz/conf/123.conf</code> file, where <code>xxx</code> would be distribution name (like <code>debian-3.0</code>) for vzctl to be able to make changes specific for this distribution.

=== IP address(es) ===
Also, you have to supply an IP for a new VE:

vzctl set 123 --ipadd x.x.x.x --save

=== venet vs. veth ===
You may use veth interface instead of venet if you need just bring old server up for seamless migration of services.
It may be nessessary if server you are migrating is badly configured and it is hard to find all hard-coded net interfaces settings and so on.

veth inteface may me included into bridge to allow seamless old installation access.

== Making adjustments ==
Since VE is a bit different than a real physical server, you have to edit some files inside your new VE.

=== /etc/inittab ===
A VE does not have real ttys, so you have to disable getty in <code>/etc/inittab</code> (i. e. <code>/vz/private/123/etc/inittab</code>).

sed -i -e '/getty/d' /vz/private/123/etc/inittab

=== /etc/mtab ===
Link <code>/etc/mtab</code> to <code>/proc/mounts</code>, for <code>df</code> to work properly:

rm -f /vz/private/123/etc/mtab
ln -s /proc/mounts /vz/private/123/etc/mtab

{{out|The problem here is VE's root filesystem (<code>/</code>) is mounted not from the VE itself, but rather from the host system. That leaves <code>/etc/mtab</code> in VE without a record for <code>/</code> being mounted, thus df doesn't show it. By linking <code>/etc/mtab → /proc/mounts</code> we make sure /etc/mtab shows what is really mounted in a VE.

Sure this is not the only way to fix df; you can just manually add a line to <code>/etc/mtab</code> telling <code>/</code> is mounted, and make sure this line will be there after a reboot.}}

=== /etc/fstab ===
Since you do not have any real disk partitions in a VE, /etc/fstab (or most part of it) is no longer needed. Empty it (excluding the line for /dev/pts):

cp /vz/private/123/etc/fstab /vz/private/123/etc/fstab.old
grep devpts /vz/private/123/etc/fstab.old > /vz/private/123/etc/fstab

You can also mount a devpts in a running (but not fully functional) VE:
vzctl exec 123 mount -t devpts none /dev/pts

=== /dev ===

==== Introduction: static /dev ====
In order for VE to work, some nodes should be present in VE's /dev. For modern distributions, udev is taking care of it. For a variety of reasons udev doesn't make much sense in a VE, so the best thing to do is to disable udev and create needed device nodes manually.

Note that in some distrubutions <code>/dev</code> is mounted on tmpfs — this will not work in case of static /dev. So what you need to do is find out where <code>/dev</code> is being mounted on tmpfs and remove this. This is highly distribution-dependent; please add info for your distro here.

After you made sure your /dev is static, populate it with needed device nodes.

==== tty device nodes ====

In order for vzctl enter to work, a VE need to have some entries in /dev. This can either be /dev/ttyp* and /dev/ptyp*, or /dev/ptmx and mounted /dev/pts.

===== /dev/ptmx =====
Check that /dev/ptmx exists. If it does not, create with:
mknod /vz/private/123/dev/ptmx c 5 2

===== /dev/pts/ =====
Check that /dev/pts exists. It's a directory, if it does not exist, create with:
mkdir /vz/private/123/dev/pts

===== /dev/ttyp* and /dev/ptyp* =====
Check that /dev/ttyp* and /dev/ptyp* files are there. If not, you have to create those, either by using /sbin/MAKEDEV, or by copying them from the host system.

To copy:
cp -a /dev/ttyp* /dev/ptyp* /vz/private/123/dev/

To recreate with MAKEDEV, either
/sbin/MAKEDEV -d /vz/private/123/dev ttyp ptyp
or
cd /vz/private/123/dev && /sbin/MAKEDEV ttyp

====/dev/null====
Make sure sure /dev/null is not a file or directory, if unsure remove and recreate, If this is not correct sshd will not start correctly
rm -f /vz/private/123/dev/null
mknod /vz/private/123/dev/null c 1 3

==== /dev/urandom ====
Check that /dev/urandom exists. If it does not, create with:
mknod /vz/private/123/dev/urandom c 1 9

===/proc===
Make sure the /proc directory exists:
ls -la /vz/private/123/ | grep proc

If it doesn't, create it:
mkdir /vz/private/123/proc

=== /etc/init.d services ===

Some system services can (or in some cases should) be disabled. A few good candidates are:

* acpid, amd (not needed)
* checkfs, checkroot (no filesystem checking is required in VE)
* clock (no clock setting is required/allowed in VE)
* consolefont (VE does not have a console)
* hdparm (VE does not have real hard drives)
* klogd (unless you use iptables to LOG some packets)
* keymaps (VE does not have a real keyboard)
* kudzu (VE does not have real hardware)
* lm_sensors (VE does not have access to hardware sensors)
* microcodectl (VE can not update CPU microcode)
* netplugd (VE does not have real Ethernet device)

To see which services are enabled:
* RedHat/Fedora/SUSE: <code>/sbin/chkconfig --list</code>
* Debian: <code>Use ' rcconf ' (ncurses) or update-rc.d
( See: http://www.debianadmin.com/manage-linux-init-or-startup-scripts.html )</code>
* Gentoo: <code>/sbin/rc-update show</code>

To disable the service:
* RedHat/Fedora/SUSE: <code>/sbin/chkconfig --del SERVICENAME </code>
* Debian: <code>' update-rc.d -f hdparm remove '</code>
* Gentoo: <code>/sbin/rc-update del SERVICENAME</code>

=== Disable old network interface ===
You should disable your old physical network interface from starting at boot time. This is distribution-dependant.

==== Fedora/CentOS/Red Hat ====
Edit /vz/private/{VEID}/etc/sysconfig/network-scripts/ifcfg-eth''x''

Make the following look like this:
ONBOOT=no

==== Debian/Ubuntu ====
Edit /etc/network/interfaces

<pre>
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
# automatically added when upgrading
auto lo eth0
iface lo inet loopback

iface eth0 inet dhcp
address 10.0.0.4
netmask 255.0.0.0
network 10.0.0.0
broadcast 10.0.0.255
</pre>

You can either comment out the eth* interface stanza(s), or take it out of the "auto" line(s).

==== openSUSE/SLES ====

Use Yast.

=== Other adjustments ===
There might be other adjustments needed. Please add those here (just above this section) if you have more info.

== Starting a new VE ==

Try to start your new VE:

vzctl start 123

Now check that everything works fine. If not, see [[#Troubleshooting]] below.

== Troubleshooting ==

=== Can't enter VE ===

If you can not enter your VE (using <code>vzctl enter</code>), you should be able to at least execute commands in it.

First, see the [[#tty device nodes]] section above.

Next, check if devpts is mounted:
vzctl exec 123 mount | grep pts

If it is not mounted, mount it:
vzctl exec 123 mount -t devpts none /dev/pts

Then, add the appropriate mount command to VE's startup scripts. On some distros, you need to have the appropriate line in VE's /etc/fstab.

In Fedora, try commenting out any '''udev''' entries in /vz/private/{VEID}/etc/rc.sysinit
vi /vz/private/{VEID}/etc/rc.sysinit
Locate the '''udev''' entry from within vim
/udev
Then comment the line similar to this:
#[ -x /sbin/start_udev ] && /sbin/start_udev

=== Other problems ===
If anything goes wrong, try to find out why and fix. If you have enough Linux experience, it can be handled. Also check out IRC and please report back on this page.

== Success Stories ==
- Debian 3.1 Sarge with MySQL, apache2, PowerDNS
--[[User:Stoffell|stoffell]] 08:41, 8 February 2007 (EST)

- Red Hat 7.2 with MySQL 3.23, apache, Chilisoft --[[User:Stoffell|stoffell]] 13:26, 9 February 2007 (EST)

- Gentoo with Courier, Postfix, MySQL, Apache2
--[[User:bfrackie|bfrackie]] 19:00, 18 March 2007 (EST)

- AltLinux Master with qmail, MySQL, Apache, etc - to Debian/testing with OpenVZ --[[User:alexkuklin|alexkuklin]]

[[Category:HOWTO]]

NFS server inside container

2007-10-27T02:02:07Z

Elronxenu: more grammar

There are two ways to setup NFS server on common [[HN]]:
use a user-space NFS server daemon or use an in-kernel implementation
of NFS server. Some peculiarities appear if you intend to run NFS server
in [[VE]].

{{Note|for information about NFS client inside VE, see [[NFS]].}}

== Kernel NFS server ==
Binary RPMs that are provided by OpenVZ community contain kernels compiled
without NFS server support. Thus you have to
[[Kernel build|recompile the kernel]] with <code>CONFIG_NFSD=m</code>. After booting in this kernel you'll be able
to use NFS server on [[HN]].
In-kernel NFS server runs kernel threads to service requests of clients.
But for security reasons kernel threads are prohibited in [[VE]]s! So you won't
be able to run NFS server inside [[VE]] without patching the kernel.

== User-space NFS server ==
Advantage of user-space NFS server is that it does not require kernel support.
Also if it crashes — there is no crash of the system: just one process dies, not the kernel!
The disadvantage of user-space NFS server is its productivity: no one can be faster than in-kernel implementation.

One well-known implementation of NFS server is "The LINUX User-Space NFS Server" by Olaf Kirch.
Some Linux distributions contain this package: Debian Sarge (<code>nfs-user-server</code>), OpenSUSE 10.0 (<code>nfs-server</code>).
For other distributions you can download sources (for example from Debian repository) and compile it.
There is a small trick you have to know about running <code>mountd</code> and <code>nfsd</code> (these two daemons and <code>portmap</code> constitute a user-space server). You should run them with the <code>-r</code> option:
<pre>
# portmap
# rpc.mountd -r
# rpc.nfsd -r
</pre>
The reason is that these daemons check the major number of the device where the directory to export resides.
If major equals 0 then daemons assume that it is NFS and don't want to re-export it. Symptoms are
that clients will always get a "permission denied" error. Simfs (the file system on which VE is located)
is associated with so called unnamed device, in which major equals 0. So, to prevent daemons from checking for
re-exporting — just use this <code>-r</code> option.

“The LINUX User-Space NFS Server” by Olaf Kirch implements NFSv2. It means that only files with sizes less
than 2GB are processed. If you intend to use such big files then you should use another user-space NFS server
implementation: [http://unfs3.sourceforge.net/ unfs3]. It implements v3 of NFS protocol standard.

== External links ==
* [http://nfs.sourceforge.net/ Linux NFS Overview, FAQ and HOWTO Documents]
* [http://www.tldp.org/LDP/nag/nag.html The Network Administrators' Guide by Olaf Kirch]
* [http://unfs3.sourceforge.net/ unfs3 homepage]
* [http://packages.qa.debian.org/n/nfs-user-server.html Overview of nfs-user-server source package]

[[Category: HOWTO]]
[[Category: Networking]]

NFS server inside container

2007-10-27T02:00:59Z

Elronxenu: Improve the grammar a little

There are two ways to setup NFS server on common [[HN]]:
use a user-space NFS server daemon or use an in-kernel implementation
of NFS server. Some peculiarities appear if you intend to run NFS server
in [[VE]].

{{Note|for information about NFS client inside VE, see [[NFS]].}}

== Kernel NFS server ==
Binary RPMs that are provided by OpenVZ community contain kernels compiled
without NFS server support. Thus you have to
[[Kernel build|recompile the kernel]] with <code>CONFIG_NFSD=m</code>. After booting in this kernel you'll be able
to use NFS server on [[HN]].
In-kernel NFS server runs kernel threads to service requests of clients.
But for security reasons kernel threads are prohibited in [[VE]]s! So you won't
be able to run NFS server inside [[VE]] without patching the kernel.

== User-space NFS server ==
Advantage of user-space NFS server is that it can be ran without any support in the kernel.
Also if it crashes — there is no crash of the system: just one process crashes, not the kernel!
The disadvantage of user-space NFS server is its productivity: no one can be faster than in-kernel implementation.

One well-known implementation of NFS server is "The LINUX User-Space NFS Server" by Olaf Kirch.
Some Linux distributions contain this package: Debian Sarge (<code>nfs-user-server</code>), OpenSUSE 10.0 (<code>nfs-server</code>).
For other distributions you can download sources (for example from Debian repository) and compile it.
There is a small trick you have to know about running <code>mountd</code> and <code>nfsd</code> (these two daemons and <code>portmap</code> constitute a user-space server). You should run them with the <code>-r</code> option:
<pre>
# portmap
# rpc.mountd -r
# rpc.nfsd -r
</pre>
The reason is that these daemons check the major number of the device where the directory to export resides.
If major equals 0 then daemons assume that it is NFS and don't want to re-export it. Symptoms are
that clients will always get a "permission denied" error. Simfs (the file system on which VE is located)
is associated with so called unnamed device, in which major equals 0. So, to prevent daemons from checking for
re-exporting — just use this <code>-r</code> option.

“The LINUX User-Space NFS Server” by Olaf Kirch implements NFSv2. It means that only files with sizes less
than 2GB are processed. If you intend to use such big files then you should use another user-space NFS server
implementation: [http://unfs3.sourceforge.net/ unfs3]. It implements v3 of NFS protocol standard.

== External links ==
* [http://nfs.sourceforge.net/ Linux NFS Overview, FAQ and HOWTO Documents]
* [http://www.tldp.org/LDP/nag/nag.html The Network Administrators' Guide by Olaf Kirch]
* [http://unfs3.sourceforge.net/ unfs3 homepage]
* [http://packages.qa.debian.org/n/nfs-user-server.html Overview of nfs-user-server source package]

[[Category: HOWTO]]
[[Category: Networking]]

DB2 installation

2007-09-06T14:47:22Z

Elronxenu: Call it a VE consistently

DB2 has been certified by IBM for use inside Virtuozzo. It works in OpenVZ too!

IBM provides a free download of DB2 Express-C which is what I
installed.

Here is a rough guide to installing DB2 into a freshly-created VE.

== Create a new VE ==

I created a new VE for the Debian distribution using debootstrap.

== Set VE resource limits appropriately ==

DB2 installation can fail and it will not be possible to operate the database if your resource limits are too low. I used these limits for a small database:

* kmemsize to 10,000,000
* privvmpages to 300,000
* shmpages to 80,000
* numproc to 150
* tcpsndbuf to 700,000
* tcprcvbuf to 700,000
* diskspace to 6,000,000

== Install additional packages ==

* libstdc++5 (required for installation)
* pdksh (required for operation?)
* ssh (may be required for operation)
* xbase-clients (for xauth)
* firefox (for post-installation)
* strace and telnet (for debugging)
* libdbi-perl gcc libc6-dev make (for building CPAN DBD::DB2 package)

== Download the DB2 Express-C package ==

DB2 Express-C version 9 is available from this page:
[[http://www-306.ibm.com/software/data/db2/express/download.html]]

You will need to register with IBM before you can download.

* Untar the received file as root
* Run exp/disk1/db2setup
* Follow the prompts:
** Setup user 'dasusr1'
** Setup user 'db2inst1' and database instance 'db2inst1'

== Post-install actions ==

This is where it gets yukky. DB2 wants to run a browser inside the VE. It wants to run Java applets inside the browser. I installed Iceweasel, but the post-install script does not recognise it. I was eventually able to hack the script to recognise and use the browser but it crashed on one of the Java applets. I think you can get by without running the post-install.

Here's what to do instead:

First, su to the instance owner:

* su - db2inst1

Try starting and stopping the database:

* db2start
* db2stop

If these don't work it means your environment variables are not set properly. IBM set these for me:

CLASSPATH=/home/db2inst1/sqllib/java/db2java.zip:/home/db2inst1/sqllib/java/db2jcc.jar:/home/db2inst1/sqllib/java/sqlj.zip:/home/db2inst1/sqllib/function:/home/db2inst1/sqllib/java/db2jcc_license_cu.jar:.
DB2INSTANCE=db2inst1
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/home/db2inst1/sqllib/bin:/home/db2inst1/sqllib/adm:/home/db2inst1/sqllib/misc

Try creating IBM's sample database:

* db2sampl

== Setup a development environment ==

I develop in perl so I was most interested in access to the database though the DBI library. I did this:

* Use CPAN to download and install DBD::DB2

If you don't use CPAN you can also do this (as root):

* Download http://search.cpan.org/CPAN/authors/id/I/IB/IBMTORDB2/DBD-DB2-1.1.tar.gz
* Untar the file and change into the directory
* perl Makefile.PL PREFIX=/usr
* make
* make test
* make install

== Setup DB2 for autostart ==

It seems that DB2 can be auto-started at VE boot time, but not auto-stopped. I used this script:

#!/bin/sh
#
# Script to start DB2 instances on bootup.
#

set -e

. /lib/lsb/init-functions

case "$1" in
start)
echo Starting DB2
/opt/ibm/db2/V9.1/instance/db2istrt
;;
stop)
;;
restart|reload)
;;
esac

exit 0

And I used this command to create the symlink to make it start at VE "boot" time:

update-rc.d db2 start 95 2 .

== Testing your installation ==

From the db2inst1 user, do:

* db2

Inside the db2 client, try:

connect to sample
grant dbadm on database to user fred
connect reset

== Enjoy! ==

Please provide feedback in the discussion (Talk) page about improvements to this HOWTO.

DB2 installation

2007-09-06T14:45:09Z

Elronxenu: Fixed grant command

DB2 has been certified by IBM for use inside Virtuozzo. It works in OpenVZ too!

IBM provides a free download of DB2 Express-C which is what I
installed.

Here is a rough guide to installing DB2 into a freshly-created VE.

== Create a new VE ==

I created a new VE for the Debian distribution using debootstrap.

== Set VE resource limits appropriately ==

DB2 installation can fail and it will not be possible to operate the database if your resource limits are too low. I used these limits for a small database:

* kmemsize to 10,000,000
* privvmpages to 300,000
* shmpages to 80,000
* numproc to 150
* tcpsndbuf to 700,000
* tcprcvbuf to 700,000
* diskspace to 6,000,000

== Install additional packages ==

* libstdc++5 (required for installation)
* pdksh (required for operation?)
* ssh (may be required for operation)
* xbase-clients (for xauth)
* firefox (for post-installation)
* strace and telnet (for debugging)
* libdbi-perl gcc libc6-dev make (for building CPAN DBD::DB2 package)

== Download the DB2 Express-C package ==

DB2 Express-C version 9 is available from this page:
[[http://www-306.ibm.com/software/data/db2/express/download.html]]

You will need to register with IBM before you can download.

* Untar the received file as root
* Run exp/disk1/db2setup
* Follow the prompts:
** Setup user 'dasusr1'
** Setup user 'db2inst1' and database instance 'db2inst1'

== Post-install actions ==

This is where it gets yukky. DB2 wants to run a browser inside the VPS. It wants to run Java applets inside the browser. I installed Iceweasel, but the post-install script does not recognise it. I was eventually able to hack the script to recognise and use the browser but it crashed on one of the Java applets. I think you can get by without running the post-install.

Here's what to do instead:

First, su to the instance owner:

* su - db2inst1

Try starting and stopping the database:

* db2start
* db2stop

If these don't work it means your environment variables are not set properly. IBM set these for me:

CLASSPATH=/home/db2inst1/sqllib/java/db2java.zip:/home/db2inst1/sqllib/java/db2jcc.jar:/home/db2inst1/sqllib/java/sqlj.zip:/home/db2inst1/sqllib/function:/home/db2inst1/sqllib/java/db2jcc_license_cu.jar:.
DB2INSTANCE=db2inst1
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/home/db2inst1/sqllib/bin:/home/db2inst1/sqllib/adm:/home/db2inst1/sqllib/misc

Try creating IBM's sample database:

* db2sampl

== Setup a development environment ==

I develop in perl so I was most interested in access to the database though the DBI library. I did this:

* Use CPAN to download and install DBD::DB2

If you don't use CPAN you can also do this (as root):

* Download http://search.cpan.org/CPAN/authors/id/I/IB/IBMTORDB2/DBD-DB2-1.1.tar.gz
* Untar the file and change into the directory
* perl Makefile.PL PREFIX=/usr
* make
* make test
* make install

== Setup DB2 for autostart ==

It seems that DB2 can be auto-started at VE boot time, but not auto-stopped. I used this script:

#!/bin/sh
#
# Script to start DB2 instances on bootup.
#

set -e

. /lib/lsb/init-functions

case "$1" in
start)
echo Starting DB2
/opt/ibm/db2/V9.1/instance/db2istrt
;;
stop)
;;
restart|reload)
;;
esac

exit 0

And I used this command to create the symlink to make it start at VE "boot" time:

update-rc.d db2 start 95 2 .

== Testing your installation ==

From the db2inst1 user, do:

* db2

Inside the db2 client, try:

connect to sample
grant dbadm on database to user fred
connect reset

== Enjoy! ==

Please provide feedback in the discussion (Talk) page about improvements to this HOWTO.

Checkpointing and live migration

2007-09-06T09:15:06Z

Elronxenu: This looks even better

CPT is an extension to the OpenVZ kernel which can save the full state of a running VE and to restore it later on the same or on a different host in a way transparent to running applications and network connections. This technique has several applications, the most important being live (zero-downtime) migration of VEs and taking an instant snapshot of a running VE for later resume, i.e. CheckPoinTing.

Before CPT, it was only possible to migrate a VE through a shutdown and subsequent reboot. The procedure not only introduces quite a long downtime for network services, it is not transparent for clients using the VE, making migration impossible when clients run some tasks which are not tolerant to shutdowns.

Compared with this old scheme, CPT allows migration of a VE in a way which is essentially invisible both for users of this VE and for external clients using network services located inside the VE. It still introduces a short delay in service, required for actual checkpoint/restore of the processes, but this delay is indistinguishable from a short interruption of network connectivity.

== Online migration ==

There is a special utility vzmigrate in the OpenVZ distribution intended to support VE migration. With its help one can perform live (a.k.a. online) migration, i.e. during migration the VE “freezes” for some time, and after migration it continues to work as though nothing had happened. Online migration can be performed with:
<pre>vzmigrate --online <host> VEID</pre>

During online migration all VE private data saved to an image file, which is transferred to the target host.

In order for vzmigrate to work without asking for a password, ssh public keys from the source host should be placed in the destination host's <code>/root/.ssh/authorized_keys</code> file. In other words, command <code>ssh root@host</code> should not ask you for a password. See [[ssh keys]] for more info.

== Manual Checkpoint and Restore Functions ==

<code>vzmigrate</code> is not strictly required to perform online migration. The <code>vzctl</code> utility, accompanied with some file system backup tools, provides enough power to do all the tasks.

A VE can be checkpointed with:
<pre>vzctl chkpnt VEID --dumpfile <path></pre>
This command saves all the state of a running VE to the dump file and stops the VE. If the option <code>--dumpfile</code> is not set, <code>vzctl</code> uses a default path <code>/vz/dump/Dump.VEID</code>.

After this it is possible to restore the VE to the same state executing:
<pre>vzctl restore VEID --dumpfile <path></pre>
If the dump file and file system is transferred to another HW node, the same command can restore the VE there with the same success.

It is a critical requirement that file system at the moment of restore must be identical to the file system at the moment of checkpointing. If this requirement is not met, depending on the severity of changes, the process of restoration can be aborted or the processes inside a VE can see this as an external corruption of open files. When a VE is restored on the same node where it was checkpointed, it is enough to not touch the file system accessible by the VE. When a VE is transferred to another node it is necessary to synchronize the VE file system before restore. <code>vzctl</code> does not provide this functionality and external tools (i.e. <code>rsync</code>) are required.

== Step-by-step Checkpoint and Restore ==

The process of checkpointing can be performed in stages. It consists of three steps.

First step – suspend the VE. At this stage CPT moves all the processes to a special beforehand known state and stops VE network interfaces. This stage can be done with:
<pre>vzctl chkpnt VEID --suspend</pre>

Second step – dumping VE. At this stage CPT saves the state of processes and global state of VE to an image file. All the process private data needs to be saved: address space, register set, opened files/pipes/sockets, System V IPC structures, current working directory, signal handlers, timers, terminal settings, user identities (uid, gid, etc), process identities (pid, pgrp, sid, etc), rlimit and other data. This stage can be done with:
<pre>vzctl chkpnt VEID --dump --dumpfile <path></pre>

Third step – killing or resuming processes. If the migration succeeds the VE can be stopped with the command:
<pre>vzctl chkpnt VEID --kill</pre>
If migration failed for some reason or if the goal was taking a snapshot of the VE state for later restore, CPT can resume the VE with:
<pre>vzctl chkpnt VEID --resume</pre>

The process of restoring consists of two steps.

The first step is to restore processes and to leave them in a special frozen state. After this step processes are ready to continue execution, however, in some cases CPT has to do some operations after a process is woken up, therefore CPT sets process return point to function in our module. This stage can be done with:
<pre>vzctl restore VEID --undump --dumpfile <path></pre>

Second step – waking up processes or killing them if the restore process failed. After CPT wakes up process, it performs necessary operations in our function and continues execution. This stage can be done with:
<pre>vzctl restore VEID --resume</pre>
or
<pre>vzctl restore VEID --kill</pre>

[[Category: Technology]]
[[Category: Concepts]]

Checkpointing and live migration

2007-09-06T09:13:13Z

Elronxenu: Tidy up the grammar

CPT is an extension to the OpenVZ kernel which can save the full state of a running VE and to restore it later on the same or on a different host in a way transparent to running applications and network connections. This technique has several applications, the most important being live (zero-downtime) migration of VEs and taking an instant snapshot of a running VE for later resume, i.e. CheckPoinTing.

Before CPT, it was only possible to migrate a VE through a shutdown and subsequent reboot. The procedure not only introduces quite a long downtime for network services, it is not transparent for clients using the VE, making migration impossible when clients run some tasks which are not tolerant to shutdowns.

Compared with this old scheme, CPT allows migration of a VE in a way which is essentially invisible both for users of this VE and for external clients using network services located inside the VE. It still introduces a short delay in service, required for actual checkpoint/restore of the processes, but this delay is indistinguishable from a short interruption of network connectivity.

== Online migration ==

There is a special utility vzmigrate in the OpenVZ distribution intended to support VE migration. With its help one can perform live (a.k.a. online) migration, i.e. during migration the VE “freezes” for some time, and after migration it continues to work as though nothing had happened. Online migration can be performed with the
<pre>vzmigrate --online <host> VEID</pre>
command. During online migration all VE private data saved to an image file, which is transferred to the target host.

In order for vzmigrate to work without asking for a password, ssh public keys from the source host should be placed in the destination host's <code>/root/.ssh/authorized_keys</code> file. In other words, command <code>ssh root@host</code> should not ask you for a password. See [[ssh keys]] for more info.

== Manual Checkpoint and Restore Functions ==

<code>vzmigrate</code> is not strictly required to perform online migration. The <code>vzctl</code> utility, accompanied with some file system backup tools, provides enough power to do all the tasks.

A VE can be checkpointed with command:
<pre>vzctl chkpnt VEID --dumpfile <path></pre>
This command saves all the state of a running VE to the dump file and stops the VE. If the option <code>--dumpfile</code> is not set, <code>vzctl</code> uses a default path <code>/vz/dump/Dump.VEID</code>.

After this it is possible to restore the VE to the same state executing:
<pre>vzctl restore VEID --dumpfile <path></pre>
If the dump file and file system is transferred to another HW node, the same command can restore the VE there with the same success.

It is a critical requirement that file system at the moment of restore must be identical to the file system at the moment of checkpointing. If this requirement is not met, depending on the severity of changes, the process of restoration can be aborted or the processes inside a VE can see this as an external corruption of open files. When a VE is restored on the same node where it was checkpointed, it is enough to not touch the file system accessible by the VE. When a VE is transferred to another node it is necessary to synchronize the VE file system before restore. <code>vzctl</code> does not provide this functionality and external tools (i.e. <code>rsync</code>) are required.

== Step-by-step Checkpoint and Restore ==

The process of checkpointing can be performed in stages. It consists of three steps.

First step – suspend the VE. At this stage CPT moves all the processes to a special beforehand known state and stops VE network interfaces. This stage can be done with the
<pre>vzctl chkpnt VEID --suspend</pre>
command.

Second step – dumping VE. At this stage CPT saves the state of processes and global state of VE to an image file. All the process private data needs to be saved: address space, register set, opened files/pipes/sockets, System V IPC structures, current working directory, signal handlers, timers, terminal settings, user identities (uid, gid, etc), process identities (pid, pgrp, sid, etc), rlimit and other data. This stage can be done with the
<pre>vzctl chkpnt VEID --dump --dumpfile <path></pre>
command.

Third step – killing or resuming processes. If the migration succeeds the VE can be stopped with the command:
<pre>vzctl chkpnt VEID --kill</pre>
If migration failed for some reason or if the goal was taking a snapshot of the VE state for later restore, CPT can resume the VE with:
<pre>vzctl chkpnt VEID --resume</pre>

The process of restoring consists of two steps.

The first step is to restore processes and to leave them in a special frozen state. After this step processes are ready to continue execution, however, in some cases CPT has to do some operations after a process is woken up, therefore CPT sets process return point to function in our module. This stage can be done with the
<pre>vzctl restore VEID --undump --dumpfile <path></pre>
command.

Second step – waking up processes or killing them if the restore process failed. After CPT wakes up process, it performs necessary operations in our function and continues execution. This stage can be done with the
<pre>vzctl restore VEID --resume
vzctl restore VEID --kill</pre>
commands.

[[Category: Technology]]
[[Category: Concepts]]

Use cases

2007-09-06T08:45:28Z

Elronxenu: Tidy grammar

{{stub}}

OpenVZ has a number of unique features that can be effectively used in the following scenarios:

== Improved security ==

Consider a Linux server used to serve mail, web site, and DNS. There are at least three different applications listening to and handling network requests, and any of them can contain security holes. Using OpenVZ, a server can be divided into three [[VE]]s, one for each application. Thus, if the DNS server is compromised, the other applications will still be left intact due to complete isolation between VEs.

== Server consolidation ==

Having a separate physical server for each application is generally a good approach, it increases availability and improves security. However, separate servers lead to increased costs of hardware and collocation, and modern hardware is often underutilized in this scenario.

With OpenVZ, you can enjoy the benefits of dedicated server without such drawbacks. Create a VE for each application and use the existing hardware more efficiently. This approach can be deployed totally transparently to users using OpenVZ.

== Development and testing ==

Developers often need access to several different Linux distributions to develop an application. Testing also needs to be performed on various software configurations. Therefore, testing and development groups often require a lot of hardware.

Alternatively, using OpenVZ developers and QAs can create multiple partitions with different Linux distributions and configurations residing on one physical server. Each VE can have its own set of packages, system libraries, configuration files. You can do snapshots and rollbacks.

== Hosting ==
* Isolated users
* A VE is like a real server, just very cheap
* Each user can have an individual versions of applications
* Much easier to administer

== Educational ==

With OpenVZ, a separate VE can be created for every student. Thus, each student gets their own root account and can do everything on their own server, e.g. experiment with firewall configuration rules (iptables).

DB2 installation

2007-09-06T08:43:53Z

Elronxenu: Last one.

DB2 has been certified by IBM for use inside Virtuozzo. It works in OpenVZ too!

IBM provides a free download of DB2 Express-C which is what I
installed.

Here is a rough guide to installing DB2 into a freshly-created VE.

== Create a new VE ==

I created a new VE for the Debian distribution using debootstrap.

== Set VE resource limits appropriately ==

DB2 installation can fail and it will not be possible to operate the database if your resource limits are too low. I used these limits for a small database:

* kmemsize to 10,000,000
* privvmpages to 300,000
* shmpages to 80,000
* numproc to 150
* tcpsndbuf to 700,000
* tcprcvbuf to 700,000
* diskspace to 6,000,000

== Install additional packages ==

* libstdc++5 (required for installation)
* pdksh (required for operation?)
* ssh (may be required for operation)
* xbase-clients (for xauth)
* firefox (for post-installation)
* strace and telnet (for debugging)
* libdbi-perl gcc libc6-dev make (for building CPAN DBD::DB2 package)

== Download the DB2 Express-C package ==

DB2 Express-C version 9 is available from this page:
[[http://www-306.ibm.com/software/data/db2/express/download.html]]

You will need to register with IBM before you can download.

* Untar the received file as root
* Run exp/disk1/db2setup
* Follow the prompts:
** Setup user 'dasusr1'
** Setup user 'db2inst1' and database instance 'db2inst1'

== Post-install actions ==

This is where it gets yukky. DB2 wants to run a browser inside the VPS. It wants to run Java applets inside the browser. I installed Iceweasel, but the post-install script does not recognise it. I was eventually able to hack the script to recognise and use the browser but it crashed on one of the Java applets. I think you can get by without running the post-install.

Here's what to do instead:

First, su to the instance owner:

* su - db2inst1

Try starting and stopping the database:

* db2start
* db2stop

If these don't work it means your environment variables are not set properly. IBM set these for me:

CLASSPATH=/home/db2inst1/sqllib/java/db2java.zip:/home/db2inst1/sqllib/java/db2jcc.jar:/home/db2inst1/sqllib/java/sqlj.zip:/home/db2inst1/sqllib/function:/home/db2inst1/sqllib/java/db2jcc_license_cu.jar:.
DB2INSTANCE=db2inst1
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/home/db2inst1/sqllib/bin:/home/db2inst1/sqllib/adm:/home/db2inst1/sqllib/misc

Try creating IBM's sample database:

* db2sampl

== Setup a development environment ==

I develop in perl so I was most interested in access to the database though the DBI library. I did this:

* Use CPAN to download and install DBD::DB2

If you don't use CPAN you can also do this (as root):

* Download http://search.cpan.org/CPAN/authors/id/I/IB/IBMTORDB2/DBD-DB2-1.1.tar.gz
* Untar the file and change into the directory
* perl Makefile.PL PREFIX=/usr
* make
* make test
* make install

== Setup DB2 for autostart ==

It seems that DB2 can be auto-started at VE boot time, but not auto-stopped. I used this script:

#!/bin/sh
#
# Script to start DB2 instances on bootup.
#

set -e

. /lib/lsb/init-functions

case "$1" in
start)
echo Starting DB2
/opt/ibm/db2/V9.1/instance/db2istrt
;;
stop)
;;
restart|reload)
;;
esac

exit 0

And I used this command to create the symlink to make it start at VE "boot" time:

update-rc.d db2 start 95 2 .

== Testing your installation ==

From the db2inst1 user, do:

* db2

Inside the db2 client, try:

connect to sample
grant all privileges to user fred (?not sure?)
connect reset

== Enjoy! ==

Please provide feedback in the discussion (Talk) page about improvements to this HOWTO.

DB2 installation

2007-09-06T08:42:12Z

Elronxenu: Tidy it up a little now

DB2 has been certified by IBM for use inside Virtuozzo. It works in OpenVZ too!

IBM provides a free download of DB2 Express-C which is what I
installed.

Here is a rough guide to installing DB2 into a freshly-created VE.

== Create a new VE ==

I created a new VE for the Debian distribution using debootstrap.

== Set VE resource limits appropriately ==

DB2 installation can fail and it will not be possible to operate the database if your resource limits are too low. I used these limits for a small database:

* kmemsize to 10,000,000
* privvmpages to 300,000
* shmpages to 80,000
* numproc to 150
* tcpsndbuf to 700,000
* tcprcvbuf to 700,000
* diskspace to 6,000,000

== Install additional packages ==

* libstdc++5 (required for installation)
* pdksh (required for operation?)
* ssh (may be required for operation)
* xbase-clients (for xauth)
* firefox (for post-installation)
* strace and telnet (for debugging)
* libdbi-perl gcc libc6-dev make (for building CPAN DBD::DB2 package)

== Download the DB2 Express-C package ==

DB2 Express-C version 9 is available from this page:
[[http://www-306.ibm.com/software/data/db2/express/download.html]]

You will need to register with IBM before you can download.

* Untar the received file as root
* Run exp/disk1/db2setup
* Follow the prompts:
** Setup user 'dasusr1'
** Setup user 'db2inst1' and database instance 'db2inst1'

== Post-install actions ==

This is where it gets yukky. DB2 wants to run a browser inside the VPS. It wants to run Java applets inside the browser. I installed Iceweasel, but the post-install script does not recognise it. I was eventually able to hack the script to recognise and use the browser but it crashed on one of the Java applets. I think you can get by without running the post-install.

Here's what to do instead:

First, su to the instance owner:

* su - db2inst1

Try starting and stopping the database:

* db2start
* db2stop

If these don't work it means your environment variables are not set properly. IBM set these for me:

CLASSPATH=/home/db2inst1/sqllib/java/db2java.zip:/home/db2inst1/sqllib/java/db2jcc.jar:/home/db2inst1/sqllib/java/sqlj.zip:/home/db2inst1/sqllib/function:/home/db2inst1/sqllib/java/db2jcc_license_cu.jar:.
DB2INSTANCE=db2inst1
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/home/db2inst1/sqllib/bin:/home/db2inst1/sqllib/adm:/home/db2inst1/sqllib/misc

Try creating IBM's sample database:

* db2sampl

== Setup a development environment ==

I develop in perl so I was most interested in access to the database though the DBI library. I did this:

* Use CPAN to download and install DBD::DB2

If you don't use CPAN you can also do this (as root):

* Download http://search.cpan.org/CPAN/authors/id/I/IB/IBMTORDB2/DBD-DB2-1.1.tar.gz
* Untar the file and change into the directory
* perl Makefile.PL PREFIX=/usr
* make
* make test
* make install

== Setup DB2 for autostart ==

It seems that DB2 can be auto-started at VE boot time, but not auto-stopped. I used this script:

#!/bin/sh
#
# Script to start DB2 instances on bootup.
#

set -e

. /lib/lsb/init-functions

case "$1" in
start)
echo Starting DB2
/opt/ibm/db2/V9.1/instance/db2istrt
;;
stop)
;;
restart|reload)
;;
esac

exit 0

And I used this command to create the symlink to make it start at VE "boot" time:

update-rc.d db2 start 95 2 .

== Testing your installation ==

From the db2inst1 user, do:

* db2

Inside the db2 client, try:

connect to sample
grant all privileges to user fred (?not sure?)
connect reset

DB2 installation

2007-09-06T08:40:14Z

Elronxenu: How to get DB2 Express-C going in a Virtual Environment

DB2 has been certified by IBM for use inside Virtuozzo. It works in OpenVZ too!

IBM provides a free download of DB2 Express-C which is what I
installed.

Here is a rough guide to installing DB2 into a freshly-created VE.

== Create a new VE ==

I created a new VE for the Debian distribution using debootstrap.

== Set VE resource limits appropriately ==

DB2 installation can fail and it will not be possible to operate the database if your resource limits are too low. I used these limits for a small database:

* kmemsize to 10,000,000
* privvmpages to 300,000
* shmpages to 80,000
* numproc to 150
* tcpsndbuf to 700,000
* tcprcvbuf to 700,000
* diskspace to 6,000,000

== Install additional packages ==

* libstdc++5 (required for installation)
* pdksh (required for operation?)
* ssh (may be required for operation)
* xbase-clients (for xauth)
* firefox (for post-installation)
* strace and telnet (for debugging)
* libdbi-perl gcc libc6-dev make (for building CPAN DBD::DB2 package)

== Download the DB2 Express-C package ==

DB2 Express-C version 9 is available from this page:
[[http://www-306.ibm.com/software/data/db2/express/download.html]]

You will need to register with IBM before you can download.

* Untar the received file as root
* Run exp/disk1/db2setup
* Follow the prompts:
* Setup user 'dasusr1'
* Setup user 'db2inst1' and database instance 'db2inst1'

== Post-install actions ==

This is where it gets yukky. DB2 wants to run a browser inside the VPS. It wants to run Java applets inside the browser. I installed Iceweasel, but the post-install script does not recognise it. I was eventually able to hack the script to recognise and use the browser but it crashed on one of the Java applets. I think you can get by without running the post-install.

Here's what to do instead:

First, su to the instance owner:

* su - db2inst1

Try starting and stopping the database:

* db2start
* db2stop

If these don't work it means your environment variables are not set properly. IBM set these for me:

* CLASSPATH=/home/db2inst1/sqllib/java/db2java.zip:/home/db2inst1/sqllib/java/db2jcc.jar:/home/db2inst1/sqllib/java/sqlj.zip:/home/db2inst1/sqllib/function:/home/db2inst1/sqllib/java/db2jcc_license_cu.jar:.
* DB2INSTANCE=db2inst1
* PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/home/db2inst1/sqllib/bin:/home/db2inst1/sqllib/adm:/home/db2inst1/sqllib/misc

Try creating IBM's sample database:

* db2sampl

== Setup a development environment ==

I develop in perl so I was most interested in access to the database though the DBI library. I did this:

* Use CPAN to download and install DBD::DB2

If you don't use CPAN you can also do this (as root):

* Download http://search.cpan.org/CPAN/authors/id/I/IB/IBMTORDB2/DBD-DB2-1.1.tar.gz
* Untar the file and change into the directory
* perl Makefile.PL PREFIX=/usr
* make
* make test
* make install

== Setup DB2 for autostart ==

It seems that DB2 can be auto-started at VE boot time, but not auto-stopped. I used this script:

#!/bin/sh
#
# Script to start DB2 instances on bootup.
#

set -e

. /lib/lsb/init-functions

case "$1" in
start)
echo Starting DB2
/opt/ibm/db2/V9.1/instance/db2istrt
;;
stop)
;;
restart|reload)
;;
esac

exit 0

And I used this command to create the symlink to make it start at VE "boot" time:

* update-rc.d db2 start 95 2 .

== Testing your installation ==

From the db2inst1 user, do:

* db2

Inside the db2 client, try:

* connect to sample
* grant all privileges to user fred (?not sure?)
* connect reset

UBC secondary parameters

2007-07-11T12:30:10Z

Elronxenu: /* kmemsize */

{{UBC toc}}

'''Secondary (dependant) UBC parameters''' are directly connected
to the [[UBC primary parameters|primary ones]] and can't be configured arbitrarily.

== kmemsize ==
Size of unswappable memory in bytes, allocated by the operating system kernel.

It includes all the kernel internal data structures associated with the
Virtual Environment's processes, except the network buffers discussed below.
These data structures reside in the first gigabyte of the computer's RAM,
so called [[UBC systemwide configuration#“Low memory”|“low memory”]].

This parameter is related to the number of processes ([[numproc]]).
Each process consumes certain amount of kernel memory —
24 kilobytes at minimum, 30–60 KB typically.
Very large processes may consume much more than that.

It is important to have a certain safety gap between the <code>barrier</code> and
the <code>limit</code> of the <code>kmemsize</code> parameter
(for example, 10%, as in [[UBC configuration examples]]). Equal <code>barrier</code> and <code>limit</code> of
the <code>kmemsize</code> parameter may lead to the situation where the kernel will
need to kill Virtual Environment's applications to keep the <code>kmemsize</code>
usage under the limit.

<code>Kmemsize</code> limits can't be set arbitrarily high.
The total amount of <code>kmemsize</code> consumable by all Virtual Environments
in the system plus the socket buffer space (see below) is limited by the
hardware resources of the system.
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].

== tcpsndbuf ==
The total size of buffers used to send data over TCP network connections.
These socket buffers reside in [[UBC systemwide configuration#“Low memory”|“low memory”]].

<code>Tcpsndbuf</code> parameter depends on number of TCP
sockets ([[numtcpsock]]) and should allow for some minimal amount of
socket buffer memory for each socket, as discussed in [[UBC consistency check]]:

<math>tcpsndbuf_{lim} - tcpsndbuf_{bar} \ge 2.5KB \cdot numtcpsock \rm.</math>

If this restriction is not satisfied, some network connections
may silently stall, being unable to transmit data.

Setting high values for <code>tcpsndbuf</code> parameter
may, but doesn't necessarily, increase performance of network communications.
Note that, unlike most other parameters, hitting <code>tcpsndbuf</code>
limits and failed socket buffer allocations
do not have strong negative effect on the applications, but just reduce
performance of network communications.

<code>Tcpsndbuf</code> limits can't be set arbitrarily high.
The total amount of <code>tcpsndbuf</code> consumable by all Virtual Environments
in the system plus the <code>kmemsize</code> and other socket buffers is limited
by the hardware resources of the system.
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].

== tcprcvbuf ==
The total size of buffers used to temporary store the data coming from TCP network connections.
These socket buffers also reside in [[UBC systemwide configuration#“Low memory”|“low memory”]].

<code>Tcprcvbuf</code> parameter depends on number of TCP
sockets ([[numtcpsock]]) and should allow for some minimal amount of
socket buffer memory for each socket, as discussed in [[UBC consistency check]]:

<math>tcprcvbuf_{lim} - tcprcvbuf_{bar} \ge 2.5KB \cdot numtcpsock \rm.</math>

If this restriction is not satisfied, some network connections
may stall, being unable to receive data, and will be terminated
after a couple of minutes.

Similarly to <code>tcpsndbuf</code>, setting high values for <code>tcprcvbuf</code>
parameter may, but doesn't necessarily, increase performance of network
communications.
Hitting <code>tcprcvbuf</code> limits and failed socket buffer allocations
do not have strong negative effect on the applications, but just reduce
performance of network communications.
However, staying above the <code>barrier</code> of <code>tcprcvbuf</code> parameter
for a long time is less harmless than for <code>tcpsndbuf</code>.
Long periods of exceeding the <code>barrier</code> may cause termination
of some connections.

<code>Tcprcvbuf</code> limits can't be set arbitrarily high.
The total amount of <code>tcprcvbuf</code> consumable by all Virtual Environments
in the system plus the <code>kmemsize</code> and other socket buffers is limited
by the hardware resources of the system.
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].

== othersockbuf ==
The total size of buffers used by local (UNIX-domain) connections between
processes inside the system (such as connections to a local database server)
and send buffers of UDP and other datagram protocols.

<code>Othersockbuf</code> parameter depends on number of non-TCP sockets (<code>[[numothersock]]</code>).

<code>Othersockbuf</code> configuration should satisfy

<math>othersockbuf_{lim} - othersockbuf_{bar} \ge 2.5KB \cdot numothersock.</math>

Increased limit for <code>othersockbuf</code> is necessary for high performance of
communications through local (UNIX-domain) sockets.
However, similarly to <code>tcpsndbuf</code>, hitting <code>othersockbuf</code> affects
the communication performance only and does not affect the functionality.

<code>Othersockbuf</code> limits can't be set arbitrarily high.
The total amount of <code>othersockbuf</code> consumable by all Virtual Environments
in the system plus the <code>kmemsize</code> and other socket buffers
is limited by the hardware resources of the system.
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].

== dgramrcvbuf ==
The total size of buffers used to temporary store the incoming packets of UDP and
other datagram protocols.

<code>Dgramrcvbuf</code> parameters depend on number of
non-TCP sockets (<code>[[numothersock]]</code>).

<code>Dgramrcvbuf</code> limits usually don't need to be high.
Only if the Virtual Environments needs to send and receive very large
datagrams, the <code>barrier</code>s for both <code>othersockbuf</code> and
<code>dgramrcvbuf</code> parameters should be raised.

Hitting <code>dgramrcvbuf</code> means that some datagrams are dropped, which may
or may not be important for application functionality.
UDP is a protocol with not guaranteed delivery, so even if the buffers
permit, the datagrams may be as well dropped later on any stage of the
processing, and applications should be prepared for it.

Unlike other socket buffer parameters, for <code>dgramrcvbuf</code>
the <code>barrier</code> should be set to the <code>limit</code>.

<code>Dgramrcvbuf</code> limits can't be set arbitrarily high.
The total amount of <code>dgramrcvbuf</code> consumable by all Virtual Environments
in the system plus the <code>kmemsize</code> and other socket buffers
is limited by the hardware resources of the system.
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].

== oomguarpages ==
The guaranteed amount of memory for the case the memory is “over-booked”
(out-of-memory kill guarantee).

<code>Oomguarpages</code> parameter is related to <code>[[vmguarpages]]</code>.
If applications start to consume more memory than the computer has,
the system faces an out-of-memory condition.
In this case the operating system will start to kill Virtual Environment's
processes to free some memory and prevent the total death
of the system. Although it happens very rarely in typical system loads,
killing processes in out-of-memory situations is a normal reaction of the
system, and it is built into every Linux kernel<ref>The possible reasons of out-of-memory situations are the excess of total <code>[[vmguarpages]]</code> guarantees the available physical resources or high memory consumption by system processes. Also, the kernel might allow some Virtual Environments to allocate memory above their <code>[[vmguarpages]]</code> guarantees when the system had a lot of free memory, and later, when other Virtual Environments claim their guarantees, the system will experience the memory shortage.</ref>.

<code>[[Oomguarpages]]</code> parameter accounts the total amount of
memory and swap space used by the processes of a particular
Virtual Environment.
The <code>barrier</code> of the <code>oomguarpages</code> parameter is the out-of-memory
guarantee.

If the current usage of memory and swap space
(the value of <code>oomguarpages</code>) plus the amount of used kernel memory
(<code>[[kmemsize]]</code>) and socket buffers is below the <code>barrier</code>,
processes in this Virtual Environment are guaranteed not to be killed in
out-of-memory situations.
If the system is in out-of-memory situation and there are several
Virtual Environments with <code>oomguarpages</code> excess, applications in the
Virtual Environment with the biggest excess will be killed first.
The <code>failcnt</code> counter of <code>oomguarpages</code> parameter
increases when a process in this Virtual Environment is killed because
of out-of-memory situation.

If the administrator needs to make sure that some application won't be
forcedly killed regardless of the application's behavior,
setting the <code>[[privvmpages]]</code> limit to a value not greater than the
<code>oomguarpages</code> guarantee significantly reduce the likelihood of
the application being killed,
and setting it to a half of the <code>oomguarpages</code> guarantee completely
prevents it.
Such configurations are not popular because they significantly reduce
the utilization of the hardware.

The meaning of the <code></code>limit for the <code>oomguarpages</code> parameter is
unspecified in the current version.

The total out-of-memory guarantees given to the Virtual Environments should
not exceed the physical capacity of the computer, as discussed in [[UBC systemwide configuration#Memory and swap space]].
If guarantees are given for more than the system has, in out-of-memory
situations applications in Virtual Environments with guaranteed level of
service and system daemons may be killed.

== privvmpages ==
Memory allocation limit.

<code>Privvmpages</code> parameter
allows controlling the amount of memory allocated by applications.

The <code>barrier</code> and the <code>limit</code> of <code>privvmpages</code> parameter
control the upper boundary of the total size of allocated memory.
Note that this upper boundary doesn't guarantee that the Virtual Environment
will be able to allocate that much memory, neither does it guarantee that
other Virtual Environments will be able to allocate their fair share of
memory.
The primary mechanism to control memory allocation is the <code>[[vmguarpages]]</code>
guarantee.

<code>Privvmpages</code> parameter accounts allocated (but, possibly,
not used yet) memory.
The accounted value is an estimation how much memory will be really consumed
when the Virtual Environment's applications start to use the allocated
memory.
Consumed memory is accounted into <code>[[oomguarpages]]</code> parameter.

Since the memory accounted into <code>privvmpages</code> may not be actually used,
the sum of current <code>privvmpages</code> values for all Virtual Environments
may exceed the RAM and swap size of the computer.

There should be a safety gap between the <code>barrier</code> and the <code>limit</code>
for <code>privvmpages</code> parameter to reduce the number of memory allocation
failures that the application is unable to handle.
This gap will be used for “high-priority” memory allocations, such
as process stack expansion.
Normal priority allocations will fail when the <code>barrier</code> if
<code>privvmpages</code> is reached.

Total <code>privvmpages</code> should correlate with the physical resources of the
computer.
Also, it is important not to allow any Virtual Environment to allocate a
significant portion of all system RAM to avoid serious service level
degradation for other VEs.
Both these configuration requirements are discussed in [[UBC systemwide configuration#Allocated memory]].

There's also an article describing how [[user pages accounting]] works.

== Units ==
<code>Oomguarpages</code> and <code>privvmpages</code>
values are measured in [[memory page]]s.
For other secondary parameters, the values are in bytes.

== System-wide limits ==
All secondary parameters are related to memory.
Total limits on memory-related parameters must not exceed the physical
resources of the computer.
The restrictions on the configuration of memory-related parameters are listed
in [[UBC systemwide configuration]].
Those restrictions are very important, because their violation may
allow any Virtual Environment cause the whole system to hang.

== Notes ==
<references/>

Installation on Debian/old

2007-07-10T07:52:24Z

Elronxenu: misc grammar updates

= Sarge-Dapper (OldStable) =
The OpenVZ packages at http://debian.systs.org/ aimed to install OpenVZ in a easy way, some tasks are even completed during the install process!

== edit apt source settings ==
Add to your "/etc/apt/sources.list"

<pre>
deb http://debian.systs.org/debian sarge openvz
</pre>

and get the new package lists

<pre>
# apt-get update
</pre>

== precompiled kernel images at debian.systs.org (dso) ==
The kernel-images on debian.systs.org (dso) use the same kernel-config taken from OpenVZ.
(most kernel-modules are built-in!)

If there is more than one CPU available (or a CPU with hyperthreading), use the kernel-smp deb.
If there is more than 4 Gb of RAM available, use the kernel-enterprise deb.
Otherwise, use the plain kernel deb (kernel).

{| class="wikitable"
|+'''Kernel flavors list'''
! Kernel type !! Description !! Hardware !! Use case
|-
! -
| 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
|}

kernel-image: i368 and amd64
<pre>
ovzkernel-2.6.9
ovzkernel-2.6.9-smp
</pre>

kernel-image: i386 only:
<pre>
ovzkernel-2.6.9-enterprise
ovzkernel-2.6.9-entnosplit
</pre>

OpenVZ tool(s) for i386 and amd64
<pre>
vzctl
vzquota
vzprocps
vzdump
</pre>

template(s) for i368 and amd64 : Debian 3.1 Minimal
<pre>
vzctl-ostmpl-debian
</pre>

== installing the kernel-images, toolset and debian-os-template ==
Example: install the stable OpenVZ kernel, tools and Debian OS Template

# aptitude install ovzkernel-2.6.9 vzctl vzquota vzdump vzctl-ostmpl-debian

If you are using GRUB, maybe you need to update the /boot/grub/menu.lst file
(can be configured at /etc/kernel-img.conf):

# /sbin/grub-update

Reboot in your new Debian Sarge OpenVZ System

# reboot

That's all :-)

Now it's time to setup your VEs with the minimal Debian-3.1 Template, create new one or download another precreated OS-Template.

= Etch (Stable) =
OpenVZ is now a part of Debian Etch repository. The packages are 'vzctl' and 'vzquota'.

== install the kernel-image ==

=== precompiled kernel images at download.openvz.org ===

A Debian OpenVZ kernel repository is online, for direct access http://download.openvz.org/kernel/debian/etch/

add to your "/etc/apt/sources.list"
<pre>
deb http://download.openvz.org/debian etch main
</pre>

Update package lists
<pre>
# apt-get update
</pre>

List downloadable OpenVZ linux-images
<pre>
# apt-cache search linux-image-2.6.18-openvz
</pre>

Install a kernel
<pre>
# apt-get install <linux-image>
</pre>

=== precompiled kernel images at debian.systs.org ===

Add to your "/etc/apt/sources.list"

<pre>
deb http://debian.systs.org/ etch openvz
</pre>

Add the signing key of debian.systs.org (dso) apt-keyring, (need root permissions)
<pre>
# wget http://debian.systs.org/dso_archiv_signing_key.asc -q -O - | apt-key add -
</pre>

and get the new package lists

<pre>
# apt-get update
</pre>

Choose a linux image (version 028stab035.1) :
<pre>
ovzkernel-2.6.18 (i386 and amd64)
ovzkernel-2.6.18-smp (i386 and amd64)
ovzkernel-2.6.18-enterprise only (i386)
</pre>

# apt-get install <linux-image>

=== or build your own kernel-image (debian way) ===

To install the kernel-source and the OpenVZ kernel patch, run:
<pre>
# apt-get install kernel-package linux-source-2.6.18 kernel-patch-openvz libncurses5-dev
</pre>

Unpack the kernel source:
<pre>
# cd /usr/src
# tar xjf linux-source-2.6.18.tar.bz2
# cd linux-source-2.6.18
</pre>

You need a kernel config.
You can use the config of the debian-kernel:
<pre>
# cp /boot/config-2.6.18-4-686 .config
</pre>

Or get a 2.6.18 kernel config from http://download.openvz.org/kernel/devel/current/configs/
<pre>
# wget http://download.openvz.org/kernel/devel/current/configs/kernel-2.6.18-028test010-i686.config.ovz -O .config
</pre>

Now you can apply the openvz kernel patch and modify your kernel-config:
<pre>
# ../kernel-patches/all/apply/openvz
# make menuconfig
</pre>

You need the following OpenVZ kernel config settings:
<pre>
(taken from OpenVZ Kernel 2.6.18-028test010.1 on 686)

Filesystem
\_ [*] Second extended fs support (CONFIG_EXT2_FS)
\_ [*] Ext3 journalling file system support (CONFIG_EXT3_FS)
\_ [M] Quota Support (CONFIG_QUOTA)
\_ [*] Compatibility with older quotactl interface (CONFIG_QUOTA_COMPAT)
\_ [*]Quota format v2 support (CONFIG_QFMT_V2)
\_ [*] VPS filesystem (CONFIG_SIM_FS)
\_ [*] Virtuozzo Disk Quota support (CONFIG_VZ_QUOTA)
\-> [*] Per-user and per-group quota in Virtuozzo quota partitions (VZ_QUOTA_UGID)

Security
\->[ ] Enable different security models

OpenVZ ... (what else :-)
\_[*] Virtual Environment support (CONFIG_VE)
\_ <M> VE calls interface (CONFIG_VE_CALLS)
\_ <M> VE networking (CONFIG_VE_NETDEV)
\_ <M> Virtual ethernet device (CONFIG_VE_ETHDEV)
\_ <M> VE device (CONFIG_VZ_DEV)
\_ [*] VE netfiltering (CONFIG_VE_IPTABLES)
\_ <M> VE watchdog module (CONFIG_VZ_WDOG)
\_ <M> Checkpointing & restoring Virtual Environments (CONFIG_VZ_CHECKPOINT)

User resources ... (User Beancounters)
\_ [*] Enable user resource accounting (CONFIG_USER_RESOURCE)
\_ [*] Account physical memory usage ( CONFIG_USER_RSS_ACCOUNTING)
\_ [*] Account disk IO (CONFIG_UBC_IO_ACCT)
\_ [*] Account swap usage (CONFIG_USER_SWAP_ACCOUNTING)
\_ [*] Report resource usage in /proc (CONFIG_USER_RESOURCE_PROC)
\_ [*] User resources debug features (CONFIG_UBC_DEBUG)
\_ [*] Debug kmemsize with cache counters (CONFIG_UBC_DEBUG_KMEM)
</pre>

INFO: Better to build the kernel-headers as well, so afterward other kernel-modules can
be built without whole kernel tree (e.g. drbd -> drbd0.7-module-source)
See also : "make-kpkg --targets"

Compile your Kernel (as user root, or you need the --rootcmd!)
<pre>
# make-kpkg --append_to_version=-1-openvz --added_patches=openvz --revision=1 --initrd binary-arch

or all above with one step

# make-kpkg --append_to_version=-1-openvz --added_patches=openvz --revision=1 --initrd --config menuconfig binary-arch
</pre>

Install the kernel and update initramfs:
<pre>
# dpkg -i ../linux-image-2.6.18-1-openvz_1_i386.deb
# update-initramfs -c -k 2.6.18-1-openvz
</pre>

<pre>
INFO: update-initramfs is done, when make-kpkg is use with --initrd option
INFO: update-grub can be configured by /etc/kernel-img.conf
</pre>

Update the bootloader (when not done above)

GRUB :

# /usr/sbin/update-grub

INFO: since the Debian ETCH-release the location of update-grub is moved from /sbin/update-grub to /usr/sbin/update-grub !

== Install the toolset ==

You need the toolset for managing OpenVZ Virtual Environments (VE)

<pre>
# apt-get install vzctl vzquota
</pre>

= modify needed settings =

If you want network access for the virtual server then you need to enable IP forwarding.

An old (before Etch) Debian Way: set "ip_forward" to yes in /etc/network/option.

# editor /etc/network/options

The new (from Etch) standard way is to use sysctl for this (see below).

In some cases you may need to enable proxy_arp for the network devices that you want your virtual hosts to be accessible on.
You can add this to a specific interface in the network configuration (/etc/network/interfaces) by the following lines, replace %DEV% with your device name (ie. eth0).

Example:

<pre>
[...]
# device: %DEV%
iface %DEV% inet static
address 192.168.0.2
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1

up sysctl -w net.ipv4.conf.%DEV%.proxy_arp=100
pre-down sysctl -w net.ipv4.conf.%DEV%.proxy_arp=0
[...]
</pre>

or use the /etc/network/if-up/ and /etc/network/if-down.d/ directories.

<pre>
INFO: # man 5 interfaces (to read more about debian's network interface configuration for ifup and ifdown)
INFO: It is recommanded to add the magic-sysrq key, to your /etc/sysctl.conf
</pre>

a (plain) OpenVZ Linux Way:

Add settings to "/etc/sysctl.conf"

<pre>
# On Hardware Node we generally need
# packet forwarding enabled and proxy arp disabled
net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 0

# Enables source route verification
net.ipv4.conf.all.rp_filter = 1

# Enables the magic-sysrq key
kernel.sysrq = 1

# TCP Explict Congestion Notification
# net.ipv4.tcp_ecn = 0

# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
</pre>

<pre>
INFO: Suggestion: Please make a symlink from /var/lib/vz to /vz as backward compability to Main OpenVZ
(Debian vz root directory is installed FHS-like to /var/lib/vz)

# ln -s /var/lib/vz /vz
</pre>

'''Before you restart your Server, keep in mind, that your system has all needed modules enabled; booting from your harddisk (e.g. hardware modules, raid system(s), lvm2 etc). May you need a INITRD (initramdisk) or compile needed kernel modules statically in.'''

# reboot

That's all!

Now it's time to create a OS Template or download another precreated OS-Template.

INFO: Suggestions: Setup your default OS Template in /etc/vz/vz.conf

[[Category: HOWTO]]
[[Category: Installation]]

Installation on Debian/old

2007-07-10T07:49:06Z

Elronxenu: cleanup

= Sarge-Dapper (OldStable) =
The OpenVZ packages at http://debian.systs.org/ aimed to install OpenVZ in a easy way, some tasks are even completed during the install process!

== edit apt source settings ==
Add to your "/etc/apt/sources.list"

<pre>
deb http://debian.systs.org/debian sarge openvz
</pre>

and get the new package lists

<pre>
# apt-get update
</pre>

== precompiled kernel images at debian.systs.org (dso) ==
The kernel-images on debian.systs.org (dso) use the same kernel-config taken from OpenVZ.
(most kernel-modules are built-in!)

If there is more than one CPU available (or a CPU with hyperthreading), use the kernel-smp deb.
If there is more than 4 Gb of RAM available, use the kernel-enterprise deb.
Otherwise, use the plain kernel deb (kernel).

{| class="wikitable"
|+'''Kernel flavors list'''
! Kernel type !! Description !! Hardware !! Use case
|-
! -
| 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
|}

kernel-image: i368 and amd64
<pre>
ovzkernel-2.6.9
ovzkernel-2.6.9-smp
</pre>

kernel-image: i386 only:
<pre>
ovzkernel-2.6.9-enterprise
ovzkernel-2.6.9-entnosplit
</pre>

OpenVZ tool(s) for i386 and amd64
<pre>
vzctl
vzquota
vzprocps
vzdump
</pre>

template(s) for i368 and amd64 : Debian 3.1 Minimal
<pre>
vzctl-ostmpl-debian
</pre>

== installing the kernel-images, toolset and debian-os-template ==
Example: install the stable OpenVZ kernel, tools and Debian OS Template

# aptitude install ovzkernel-2.6.9 vzctl vzquota vzdump vzctl-ostmpl-debian

If you are using GRUB, maybe you need to update the /boot/grub/menu.lst file
(can be configured at /etc/kernel-img.conf):

# /sbin/grub-update

Reboot in your new Debian Sarge OpenVZ System

# reboot

That's all :-)

Now it's time to setup your VEs with the minimal Debian-3.1 Template, create new one or download another precreated OS-Template.

= Etch (Stable) =
OpenVZ is now a part of Debian Etch repository.

== install the kernel-image ==

=== precompiled kernel images at download.openvz.org ===

a Debian OpenVZ kernel repository is online, for direct access http://download.openvz.org/kernel/debian/etch/

add to your "/etc/apt/sources.list"
<pre>
deb http://download.openvz.org/debian etch main
</pre>

update package lists
<pre>
# apt-get update
</pre>

list downloadable OpenVZ linux-images
<pre>
# apt-cache search linux-image-2.6.18-openvz
</pre>

install a kernel
<pre>
# apt-get install <linux-image>
</pre>

=== precompiled kernel images at debian.systs.org ===

Add to your "/etc/apt/sources.list"

<pre>
deb http://debian.systs.org/ etch openvz
</pre>

Add the signing key of debian.systs.org (dso) apt-keyring, (need root permissions)
<pre>
# wget http://debian.systs.org/dso_archiv_signing_key.asc -q -O - | apt-key add -
</pre>

and get the new package lists

<pre>
# apt-get update
</pre>

linux-image (version 028stab035.1) :
<pre>
ovzkernel-2.6.18 (i386 and amd64)
ovzkernel-2.6.18-smp (i386 and amd64)
ovzkernel-2.6.18-enterprise only (i386)
</pre>

# apt-get install <linux-image>

=== or build your own kernel-image (debian way) ===

To install the kernel-source and the OpenVZ kernel patch, run:
<pre>
# apt-get install kernel-package linux-source-2.6.18 kernel-patch-openvz libncurses5-dev
</pre>

Unpack the kernel-source:
<pre>
# cd /usr/src
# tar xjf linux-source-2.6.18.tar.bz2
# cd linux-source-2.6.18
</pre>

You need a kernel config.
You can use the config of the debian-kernel:
<pre>
# cp /boot/config-2.6.18-4-686 .config
</pre>

Or get a 2.6.18 kernel config from http://download.openvz.org/kernel/devel/current/configs/
<pre>
# wget http://download.openvz.org/kernel/devel/current/configs/kernel-2.6.18-028test010-i686.config.ovz -O .config
</pre>

Now you can apply openvz kernel patch and modify your kernel-config:
<pre>
# ../kernel-patches/all/apply/openvz
# make menuconfig
</pre>

You need following OpenVZ kernel config settings:
<pre>
(taken from a OpenVZ Kernel 2.6.18-028test010.1 on 686)

Filesystem
\_ [*] Second extended fs support (CONFIG_EXT2_FS)
\_ [*] Ext3 journalling file system support (CONFIG_EXT3_FS)
\_ [M] Quota Support (CONFIG_QUOTA)
\_ [*] Compatibility with older quotactl interface (CONFIG_QUOTA_COMPAT)
\_ [*]Quota format v2 support (CONFIG_QFMT_V2)
\_ [*] VPS filesystem (CONFIG_SIM_FS)
\_ [*] Virtuozzo Disk Quota support (CONFIG_VZ_QUOTA)
\-> [*] Per-user and per-group quota in Virtuozzo quota partitions (VZ_QUOTA_UGID)

Security
\->[ ] Enable different security models

OpenVZ ... (what else :-)
\_[*] Virtual Environment support (CONFIG_VE)
\_ <M> VE calls interface (CONFIG_VE_CALLS)
\_ <M> VE networking (CONFIG_VE_NETDEV)
\_ <M> Virtual ethernet device (CONFIG_VE_ETHDEV)
\_ <M> VE device (CONFIG_VZ_DEV)
\_ [*] VE netfiltering (CONFIG_VE_IPTABLES)
\_ <M> VE watchdog module (CONFIG_VZ_WDOG)
\_ <M> Checkpointing & restoring Virtual Environments (CONFIG_VZ_CHECKPOINT)

User resources ... (User Beancounters)
\_ [*] Enable user resource accounting (CONFIG_USER_RESOURCE)
\_ [*] Account physical memory usage ( CONFIG_USER_RSS_ACCOUNTING)
\_ [*] Account disk IO (CONFIG_UBC_IO_ACCT)
\_ [*] Account swap usage (CONFIG_USER_SWAP_ACCOUNTING)
\_ [*] Report resource usage in /proc (CONFIG_USER_RESOURCE_PROC)
\_ [*] User resources debug features (CONFIG_UBC_DEBUG)
\_ [*] Debug kmemsize with cache counters (CONFIG_UBC_DEBUG_KMEM)
</pre>

<pre>
INFO: Better to build the kernel-headers as well, so afterward other kernel-modules can
built without whole kernel tree (e.g. drbd -> drbd0.7-module-source)
See also :
# make-kpkg --targets
</pre>

Compile your Kernel (as user root, or you need the --rootcmd!)
<pre>
# make-kpkg --append_to_version=-1-openvz --added_patches=openvz --revision=1 --initrd binary-arch

or all above with one step

# make-kpkg --append_to_version=-1-openvz --added_patches=openvz --revision=1 --initrd --config menuconfig binary-arch
</pre>

Install the kernel and update initramfs:
<pre>
# dpkg -i ../linux-image-2.6.18-1-openvz_1_i386.deb
# update-initramfs -c -k 2.6.18-1-openvz
</pre>

<pre>
INFO: update-initramfs is done, when make-kpkg is use with --initrd option
INFO: update-grub can be configured by /etc/kernel-img.conf
</pre>

Update the bootloader (when not done above)

GRUB :

# /usr/sbin/update-grub

INFO: since the Debian ETCH-release the location of update-grub is moved from /sbin/update-grub to /usr/sbin/update-grub !

== Install the toolset ==

You need the toolset for managing OpenVZ Virtual Environments (VE)

<pre>
# apt-get install vzctl vzquota
</pre>

= modify needed settings =

If you want network access for the virtual server then you need to enable IP forwarding.

An old (before Etch) Debian Way: set "ip_forward" to yes in /etc/network/option.

# editor /etc/network/options

The new (from Etch) standard way is to use sysctl for this (see below).

In some cases you may need to enable proxy_arp for the network devices that you want your virtual hosts to be accessible on.
You can add this to a specific interface in the network configuration (/etc/network/interfaces) by the following lines, replace %DEV% with your device name (ie. eth0).

Example:

<pre>
[...]
# device: %DEV%
iface %DEV% inet static
address 192.168.0.2
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1

up sysctl -w net.ipv4.conf.%DEV%.proxy_arp=100
pre-down sysctl -w net.ipv4.conf.%DEV%.proxy_arp=0
[...]
</pre>

or use the /etc/network/if-up/ and /etc/network/if-down.d/ directories.

<pre>
INFO: # man 5 interfaces (to read more about debian's network interface configuration for ifup and ifdown)
INFO: It is recommanded to add the magic-sysrq key, to your /etc/sysctl.conf
</pre>

a (plain) OpenVZ Linux Way:

Add settings to "/etc/sysctl.conf"

<pre>
# On Hardware Node we generally need
# packet forwarding enabled and proxy arp disabled
net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 0

# Enables source route verification
net.ipv4.conf.all.rp_filter = 1

# Enables the magic-sysrq key
kernel.sysrq = 1

# TCP Explict Congestion Notification
# net.ipv4.tcp_ecn = 0

# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
</pre>

<pre>
INFO: Suggestion: Please make a symlink from /var/lib/vz to /vz as backward compability to Main OpenVZ
(Debian vz root directory is installed FHS-like to /var/lib/vz)

# ln -s /var/lib/vz /vz
</pre>

'''Before you restart your Server, keep in mind, that your system has all needed modules enabled; booting from your harddisk (e.g. hardware modules, raid system(s), lvm2 etc). May you need a INITRD (initramdisk) or compile needed kernel modules statically in.'''

# reboot

That's all!

Now it's time to create a OS Template or download another precreated OS-Template.

INFO: Suggestions: Setup your default OS Template in /etc/vz/vz.conf

[[Category: HOWTO]]
[[Category: Installation]]

Installation on Debian/old

2007-07-10T07:45:21Z

Elronxenu: /* install the toolset */

= Sarge-Dapper (OldStable) =
The OpenVZ packages at http://debian.systs.org/ aimed to install OpenVZ in a easy way, some tasks are even completed during the install process!

== edit apt source settings ==
Add to your "/etc/apt/sources.list"

<pre>
deb http://debian.systs.org/debian sarge openvz
</pre>

and get the new package lists

<pre>
# apt-get update
</pre>

== precompiled kernel images at debian.systs.org (dso) ==
The kernel-images on debian.systs.org (dso) use the same kernel-config taken from OpenVZ.
(most kernel-modules are built-in!)

If there is more than one CPU available (or a CPU with hyperthreading), use the kernel-smp deb.
If there is more than 4 Gb of RAM available, use the kernel-enterprise deb.
Otherwise, use the plain kernel deb (kernel).

{| class="wikitable"
|+'''Kernel flavors list'''
! Kernel type !! Description !! Hardware !! Use case
|-
! -
| 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
|}

kernel-image: i368 and amd64
<pre>
ovzkernel-2.6.9
ovzkernel-2.6.9-smp
</pre>

kernel-image: i386 only:
<pre>
ovzkernel-2.6.9-enterprise
ovzkernel-2.6.9-entnosplit
</pre>

OpenVZ tool(s) for i386 and amd64
<pre>
vzctl
vzquota
vzprocps
vzdump
</pre>

template(s) for i368 and amd64 : Debian 3.1 Minimal
<pre>
vzctl-ostmpl-debian
</pre>

== installing the kernel-images, toolset and debian-os-template ==
Example: install the stable OpenVZ kernel, tools and Debian OS Template

# aptitude install ovzkernel-2.6.9 vzctl vzquota vzdump vzctl-ostmpl-debian

Maybe you need to update your "linux-loader" (can be configured at /etc/kernel-img.conf)

for the "GRUB":

# /sbin/grub-update

Reboot in your new Debian Stable OpenVZ System

# reboot

That's all :-)

Now it's time to setup your VE's with the minimal Debian-3.1 Template, create new one or download another precreated OS-Template.

= Etch (Stable) =
OpenVZ is now a part of Debian Etch repository.

== install the kernel-image ==

=== precompiled kernel images at download.openvz.org ===

a Debian OpenVZ kernel repository is online, for direct access http://download.openvz.org/kernel/debian/etch/

add to your "/etc/apt/sources.list"
<pre>
deb http://download.openvz.org/debian etch main
</pre>

update package lists
<pre>
# apt-get update
</pre>

list downloadable OpenVZ linux-images
<pre>
# apt-cache search linux-image-2.6.18-openvz
</pre>

install a kernel
<pre>
# apt-get install <linux-image>
</pre>

=== precompiled kernel images at debian.systs.org ===

Add to your "/etc/apt/sources.list"

<pre>
deb http://debian.systs.org/ etch openvz
</pre>

Add the signing key of debian.systs.org (dso) apt-keyring, (need root permissions)
<pre>
# wget http://debian.systs.org/dso_archiv_signing_key.asc -q -O - | apt-key add -
</pre>

and get the new package lists

<pre>
# apt-get update
</pre>

linux-image (version 028stab035.1) :
<pre>
ovzkernel-2.6.18 (i386 and amd64)
ovzkernel-2.6.18-smp (i386 and amd64)
ovzkernel-2.6.18-enterprise only (i386)
</pre>

# apt-get install <linux-image>

=== or build your own kernel-image (debian way) ===

To install the kernel-source and the OpenVZ kernel patch, run:
<pre>
# apt-get install kernel-package linux-source-2.6.18 kernel-patch-openvz libncurses5-dev
</pre>

Unpack the kernel-source:
<pre>
# cd /usr/src
# tar xjf linux-source-2.6.18.tar.bz2
# cd linux-source-2.6.18
</pre>

You need a kernel config.
You can use the config of the debian-kernel:
<pre>
# cp /boot/config-2.6.18-4-686 .config
</pre>

Or get a 2.6.18 kernel config from http://download.openvz.org/kernel/devel/current/configs/
<pre>
# wget http://download.openvz.org/kernel/devel/current/configs/kernel-2.6.18-028test010-i686.config.ovz -O .config
</pre>

Now you can apply openvz kernel patch and modify your kernel-config:
<pre>
# ../kernel-patches/all/apply/openvz
# make menuconfig
</pre>

You need following OpenVZ kernel config settings:
<pre>
(taken from a OpenVZ Kernel 2.6.18-028test010.1 on 686)

Filesystem
\_ [*] Second extended fs support (CONFIG_EXT2_FS)
\_ [*] Ext3 journalling file system support (CONFIG_EXT3_FS)
\_ [M] Quota Support (CONFIG_QUOTA)
\_ [*] Compatibility with older quotactl interface (CONFIG_QUOTA_COMPAT)
\_ [*]Quota format v2 support (CONFIG_QFMT_V2)
\_ [*] VPS filesystem (CONFIG_SIM_FS)
\_ [*] Virtuozzo Disk Quota support (CONFIG_VZ_QUOTA)
\-> [*] Per-user and per-group quota in Virtuozzo quota partitions (VZ_QUOTA_UGID)

Security
\->[ ] Enable different security models

OpenVZ ... (what else :-)
\_[*] Virtual Environment support (CONFIG_VE)
\_ <M> VE calls interface (CONFIG_VE_CALLS)
\_ <M> VE networking (CONFIG_VE_NETDEV)
\_ <M> Virtual ethernet device (CONFIG_VE_ETHDEV)
\_ <M> VE device (CONFIG_VZ_DEV)
\_ [*] VE netfiltering (CONFIG_VE_IPTABLES)
\_ <M> VE watchdog module (CONFIG_VZ_WDOG)
\_ <M> Checkpointing & restoring Virtual Environments (CONFIG_VZ_CHECKPOINT)

User resources ... (User Beancounters)
\_ [*] Enable user resource accounting (CONFIG_USER_RESOURCE)
\_ [*] Account physical memory usage ( CONFIG_USER_RSS_ACCOUNTING)
\_ [*] Account disk IO (CONFIG_UBC_IO_ACCT)
\_ [*] Account swap usage (CONFIG_USER_SWAP_ACCOUNTING)
\_ [*] Report resource usage in /proc (CONFIG_USER_RESOURCE_PROC)
\_ [*] User resources debug features (CONFIG_UBC_DEBUG)
\_ [*] Debug kmemsize with cache counters (CONFIG_UBC_DEBUG_KMEM)
</pre>

<pre>
INFO: Better to build the kernel-headers as well, so afterward other kernel-modules can
built without whole kernel tree (e.g. drbd -> drbd0.7-module-source)
See also :
# make-kpkg --targets
</pre>

Compile your Kernel (as user root, or you need the --rootcmd!)
<pre>
# make-kpkg --append_to_version=-1-openvz --added_patches=openvz --revision=1 --initrd binary-arch

or all above with one step

# make-kpkg --append_to_version=-1-openvz --added_patches=openvz --revision=1 --initrd --config menuconfig binary-arch
</pre>

Install the kernel and update initramfs:
<pre>
# dpkg -i ../linux-image-2.6.18-1-openvz_1_i386.deb
# update-initramfs -c -k 2.6.18-1-openvz
</pre>

<pre>
INFO: update-initramfs is done, when make-kpkg is use with --initrd option
INFO: update-grub can be configured by /etc/kernel-img.conf
</pre>

Update the bootloader (when not done above)

GRUB :

# /usr/sbin/update-grub

INFO: since the Debian ETCH-release the location of update-grub is moved from /sbin/update-grub to /usr/sbin/update-grub !

== Install the toolset ==

You need the toolset for managing OpenVZ Virtual Environments (VE)

<pre>
# apt-get install vzctl vzquota
</pre>

= modify needed settings =

If you want network access for the virtual server then you need to enable IP forwarding.

An old (before Etch) Debian Way: set "ip_forward" to yes in /etc/network/option.

# editor /etc/network/options

The new (from Etch) standard way is to use sysctl for this (see below).

In some cases you may need to enable proxy_arp for the network devices that you want your virtual hosts to be accessible on.
You can add this to a specific interface in the network configuration (/etc/network/interfaces) by the following lines, replace %DEV% with your device name (ie. eth0).

Example:

<pre>
[...]
# device: %DEV%
iface %DEV% inet static
address 192.168.0.2
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1

up sysctl -w net.ipv4.conf.%DEV%.proxy_arp=100
pre-down sysctl -w net.ipv4.conf.%DEV%.proxy_arp=0
[...]
</pre>

or use the /etc/network/if-up/ and /etc/network/if-down.d/ directories.

<pre>
INFO: # man 5 interfaces (to read more about debian's network interface configuration for ifup and ifdown)
INFO: It is recommanded to add the magic-sysrq key, to your /etc/sysctl.conf
</pre>

a (plain) OpenVZ Linux Way:

Add settings to "/etc/sysctl.conf"

<pre>
# On Hardware Node we generally need
# packet forwarding enabled and proxy arp disabled
net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 0

# Enables source route verification
net.ipv4.conf.all.rp_filter = 1

# Enables the magic-sysrq key
kernel.sysrq = 1

# TCP Explict Congestion Notification
# net.ipv4.tcp_ecn = 0

# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
</pre>

<pre>
INFO: Suggestion: Please make a symlink from /var/lib/vz to /vz as backward compability to Main OpenVZ
(Debian vz root directory is installed FHS-like to /var/lib/vz)

# ln -s /var/lib/vz /vz
</pre>

'''Before you restart your Server, keep in mind, that your system has all needed modules enabled; booting from your harddisk (e.g. hardware modules, raid system(s), lvm2 etc). May you need a INITRD (initramdisk) or compile needed kernel modules statically in.'''

# reboot

That's all!

Now it's time to create a OS Template or download another precreated OS-Template.

INFO: Suggestions: Setup your default OS Template in /etc/vz/vz.conf

[[Category: HOWTO]]
[[Category: Installation]]

Kernel configuration

2007-07-10T07:41:23Z

Elronxenu: more grammar

This article summarises various kernel configuration issues.

== OpenVZ related kernel config options ==

Please make sure the following config options are enabled
in your kernel .config file before compilation process:
CONFIG_SCHED_VCPU=y
CONFIG_FAIRSCHED=y

CONFIG_SIM_FS=m
CONFIG_VZ_QUOTA=m
# CONFIG_VZ_QUOTA_UNLOAD is not set
CONFIG_VZ_QUOTA_UGID=y

CONFIG_VE=y
CONFIG_VE_CALLS=m
CONFIG_VZ_GENCALLS=y
CONFIG_VE_NETDEV=m
CONFIG_VE_ETHDEV=m
CONFIG_VZ_DEV=m
CONFIG_VE_IPTABLES=y
CONFIG_VZ_WDOG=m

CONFIG_VZ_CHECKPOINT=m

{{Note|On architectures that do not currently support checkpointing (i.e. ppc and sparc) <code>CONFIG_VZ_CHECKPOINT</code> should be set to <code>n</code>}}

== ACPI sleep ==

It is a bit tricky to make ACPI sleep and OpenVZ work together.

ACPI sleep is enabled by <code>ACPI_SLEEP</code> kernel option. The following dependencies are declared in kernel configs:

ACPI_SLEEP depends on X86 && (!SMP || SUSPEND_SMP)
SUSPEND_SMP depends on HOTPLUG_CPU && X86 && PM
FAIRSCHED depends on SCHED_VCPU

And <code>SCHED_VCPU</code> is incompatible with <code>HOTPLUG_CPU</code>:

./kernel/cpu.c:#error "CONFIG_HOTPLUG_CPU isn't supported with CONFIG_SCHED_VCPU"

On a non-SMP machine, you may disable <code>SMP</code>, this will resolve the conflict.

If you have an SMP machine, you can only disable <code>FAIRSCHED</code> and <code>SCHED_VCPU</code>. It will reduce some isolation between VEs (CPU scheduling will be performed per-task, not per-VE, and <code>cpuunits</code> and <code>cpulimit</code> settings will not take effect), but it is an acceptable solution if your VEs are trusted (and it's hard to imagine untrusted VEs on a notebook.)

[[Category:Kernel]]
[[Category:HOWTO]]

Kernel configuration

2007-07-10T07:37:04Z

Elronxenu: spelling, grammar

This article summarises various kernel configuration issues.

== OpenVZ related kernel config options ==

Please make sure the following config options are enabled
in your kernel .config file before compilation process:
CONFIG_SCHED_VCPU=y
CONFIG_FAIRSCHED=y

CONFIG_SIM_FS=m
CONFIG_VZ_QUOTA=m
# CONFIG_VZ_QUOTA_UNLOAD is not set
CONFIG_VZ_QUOTA_UGID=y

CONFIG_VE=y
CONFIG_VE_CALLS=m
CONFIG_VZ_GENCALLS=y
CONFIG_VE_NETDEV=m
CONFIG_VE_ETHDEV=m
CONFIG_VZ_DEV=m
CONFIG_VE_IPTABLES=y
CONFIG_VZ_WDOG=m

CONFIG_VZ_CHECKPOINT=m

{{Note|On architectures that do not currently support checkpointing (i.e. ppc and sparc) <code>CONFIG_VZ_CHECKPOINT</code> should be set to <code>n</code>}}

== ACPI sleep ==

It is a bit tricky to make ACPI sleep and OpenVZ work together.

ACPI sleep is enabled by <code>ACPI_SLEEP</code> kernel option. The following dependencies are declared in kernel configs:

ACPI_SLEEP depends on X86 && (!SMP || SUSPEND_SMP)
SUSPEND_SMP depends on HOTPLUG_CPU && X86 && PM
FAIRSCHED depends on SCHED_VCPU

And <code>SCHED_VCPU</code> is incompatible with <code>HOTPLUG_CPU</code>:

./kernel/cpu.c:#error "CONFIG_HOTPLUG_CPU isn't supported with CONFIG_SCHED_VCPU"

On non-SMP machine, you may disable <code>SMP</code>, this will resolve the conflict.

If you have SMP machine, you can only disable <code>FAIRSCHED</code> and <code>SCHED_VCPU</code>. It will reduce some isolation between VEs (CPU scheduling will be performed per-task, not per-VE, and <code>cpuunits</code> and <code>cpulimit</code> settings will not take effect), but it is an acceptable solution if your VEs are trusted (and it's hard to imagine untrusted VEs on a notebook.)

[[Category:Kernel]]
[[Category:HOWTO]]