OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Checkpointing and live migration

2018-01-29T17:34:55Z

Avagin:

<translate>

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.


{{Note|In OpenVZ 7, CPT is replaced by our sub-project [http://criu.org CRIU]}}

== 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>

== See also == 


* http://criu.org/
</translate>

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

Vzctl for upstream kernel

2014-01-19T19:20:00Z

Avagin:

{{DISPLAYTITLE: vzctl for upstream kernel}}

'''This article describes using OpenVZ tool vzctl as an alternative to LXC tools.'''

Recent vzctl releases (starting from version 4.0) can be used with upstream (non-OpenVZ) Linux kernels (that essentially means any recent 3.x kernel). At the moment, it provides just basic functionality.
It is currently possible to create, start and stop a container with the same steps as one would use for a normal OpenVZ container. Other features may be present with limited functionality, while some are not present at all. We appreciate all bug reports, please file to [http://bugzilla.openvz.org/enter_bug.cgi?component=vzctl bugzilla].

Running vzctl on upstream kernels is considered an experimental feature. See [[#Limitations]] below.

== Installation ==

{{Note|This section describes installation for RPM-based distros. See [[#Building]] below if you want to compile vzctl from source.}}

First, set up OpenVZ yum repository. Download [[download:openvz.repo|openvz.repo]] file and put it to your <code>/etc/yum.repos.d/</code> repository,
and import OpenVZ GPG key used for signing RPM packages. This can be achieved by the following commands, as root:
<pre><nowiki>
wget -P /etc/yum.repos.d/ http://download.openvz.org/openvz.repo
rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ
</nowiki></pre>
In case you can not cd to /etc/yum.repos.d, it means either yum is not installed on your system, or yum version is too old.

Then, install vzctl-core package:

yum install vzctl-core

== Usage ==

For supported features, usage is expected to be the same as standard vzctl tool. See {{man|vzctl|8}} for more information.

=== Networking ===
{{Note|IP mode networking (--ipadd / --ipdel) is currently not supported}}

Networking is available through the switches <code>--netdev_add</code>, <code>--netif_add</code>, and their respective deletion counterparts.
Unfortunately now it requires some manual configuration.

== Bridged networking ==

The following example assumes
* you already have a bridge configured on the host system
* bridge interface name is virbr0
* CT is running Red Hat like distro (CentOS)

vzctl set $CTID --netif_add eth0,,,,virbr0 --save

echo "NETWORKING=yes" > /vz/private/$CTID/etc/sysconfig/network

cat << EOF > /vz/private/$CTID/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
EOF

vzctl start $CTID

After this, you can find CT IP using this:
# ip netns exec $CTID ip address list

== Limitations ==

{{Note|We recommend using [[Download/kernel/rhel6|OpenVZ kernel]] for features, stability and security}}

The following vzctl commands are not working at all with the non-OpenVZ kernel:

* <code>quotaon</code>/<code>quotaoff</code>/<code>quotainit</code> (vzquota-specific)
* <code>convert</code>, <code>compact</code>, <code>snapshot*</code> (ploop-specific)
* <code>console</code> (needs a virtual /dev/console, /dev/ttyN device)
* <code>chkpnt</code>, <code>restore</code> (currently need OpenVZ-kernel-specific checkpointing, [http://criu.org/ CRIU] will be supported later)

The following binaries are not ported to work on top of upstream kernel:
* vzlist
* vzcalc
* vzcfgvalidate
* vzcpucheck
* vzmemcheck
* vzmigrate
* vzeventd
* vzpid
* vzsplit
* vzubc

=== /proc and /sys ===
Software that depend on information supplied by the proc filesystem may not work correctly, since there is not a full solution for full /proc virtualization. For instance, /proc/stat is not yet virtualized, and top will show distorted values.

=== Resource management ===

With non-OpenVZ kernel, setting resources like <code>--ram</code> and <code>--cpuunits</code> works, but there their effect is dependent on what the current kernel supports, through the cgroups subsystem. When a particular cgroup file is present, it will be used. Currently, vzctl will search for the following files:
* cpu.cfs_quota_us
* cpu.shares
* cpuset.cpus
* memory.limit_in_bytes
* memory.memsw.limit_in_bytes
* memory.kmem.limit_in_bytes
* memory.kmem.tcp.limit_in_bytes

== Building ==

In case you don't want to use packages provided by OpenVZ (available from [[Download/vzctl]]), but rather would like to compile vzctl from sources, read on.

=== Dependencies ===

The following software needs to be installed on your system:

* iproute2 >= 3.0.0 (runtime only)
* libcgroup >= 0.38

=== Download ===

You can get the latest released version from [[Download/vzctl/{{Latest vzctl}}#sources]] or directly from [[download:utils/vzctl/current/src/]].

If you are living on the bleeding edge, get vzctl sources from git. Then run autogen.sh to recreate auto* files:

git clone <nowiki>git://git.openvz.org/pub/vzctl</nowiki>
cd vzctl
./autogen.sh

=== Compile ===

Usual <code>./configure && make</code> should do. But you probably want to specify more options. It makes sense to:

* enable cgroup support
* add <code>--without-ploop</code> (unless you want [[ploop]] compiled it) because otherwise you will need ploop lib headers (available from [[Download/ploop]]).
* enable bash completion support
* set prefix to /usr

See <code>./configure --help</code> output for more details and options available.

So, the command will look like:

$ ./configure --with-cgroup --without-ploop --enable-bashcomp --prefix=/usr
$ make -j4

=== Install ===

# make install
=== FAQ ===

# A container doesn't boot and udevd is in a process list
#: udev doesn't work, because uevent-s are not virtualized yet. If you don't know how to disable it, you can remove the package.
# You can't enter in CT and vzctl returns en error about pty
Unable to open pty: No such file or directory
#: If a CT is executed in a user namespace, devpts must be mounted with the newinstance option. You can add this option in /etc/fstab.

Vzctl for upstream kernel

2012-09-13T14:59:38Z

Avagin: /* Networking */

Since version 4.0, vzctl tool can be used with upstream (non-OpenVZ) Linux kernels (that essentially means any recent 3.x kernel). At the moment, it provides just basic functionality.
It is currently possible to create and start a container with the same steps as one would use for a normal OpenVZ container. Other features may be present with limited functionality, while some are not present at all.

{{Warning|Running vzctl on upstream kernels is considered an experimental feature. See [[#Limitatons]] below.}}

== Installation ==

{{Note|This section describes installation for RPM-based distros. See [[#Building]] below if you want to compile vzctl from source.}}

First, set up OpenVZ yum repository. Download [[download:openvz.repo|openvz.repo]] file and put it to your <code>/etc/yum.repos.d/</code> repository,
and import OpenVZ GPG key used for signing RPM packages. This can be achieved by the following commands, as root:
<pre><nowiki>
wget -P /etc/yum.repos.d/ http://download.openvz.org/openvz.repo
rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ
</nowiki></pre>
In case you can not cd to /etc/yum.repos.d, it means either yum is not installed on your system, or yum version is too old.

Then, install vzctl-core package:

yum install vzctl-core

== Usage ==

For supported features, usage is expected to be the same as standard vzctl tool. See {{man|vzctl|8}} for more information.

=== Networking ===

Networking is available through the switches --netdev_add, --netif_add, and their respective deletion counterparts.
In this case [[Virtual Ethernet device]] is added in [[CT]].

One life hack may be useful while "vzctl enter" doesn't work.
If you use DHCP and don't know which an IP address is in CT, you can find it in /vz/root/[CTID]/var/log/message.

"ip netns exec" can help you too, but it doesn't work sometimes.
$ ip netns exec [CTID] ip a

IP mode networking (--ipadd / --ipdel) is currently not supported.

== Limitations ==

The following vzctl commands are not working at all:
* <code>quotaon</code>/<code>quotaoff</code>/<code>quotainit</code> (vzquota-specific)
* <code>convert</code>, <code>compact</code>, <code>snapshot*</code> (ploop-specific)
* <code>console</code> (needs a virtual /dev/console, /dev/ttyN device)
* <code>enter</code>, <code>exec</code> and <code>runscript</code> (need pidns entering support)
* <code>chkpnt</code>, <code>restore</code> (currently need OpenVZ-kernel-specific checkpointing, [http://crui.org/ CRIU] will be supported later)

The following commands have severe limitations:
* <code>stop</code>. A container can be stopped from inside (say if one is connected to CT over ssh) in case the underlying kernel supports rebooting a PID namespace (> 3.4). Using vzctl, the "stop" command is not supported, unless accompanied by the --fast switch, which will simply forceably kill all processes in the container.

The following binaries are not ported to work on top of upstream kernel:
* vzlist
* vzcalc
* vzcfgvalidate
* vzcpucheck
* vzmemcheck
* vzmigrate
* vzeventd
* vzpid
* vzsplit
* vzubc

=== /proc and /sys ===
Software that depend on information supplied by the proc filesystem may not work correctly, since there is not a full solution for full /proc virtualization. For instance, /proc/stat is not yet virtualized, and top will show distorted values.

=== Resource management ===

Setting resources like <code>--ram</code> and <code>--cpuunits</code> work, but there their effect is dependent on what the current kernel supports, through the cgroups subsystem. When a particular cgroup file is present, it will be used. Currently, vzctl will search for the following files:
* cpu.cfs_quota_us
* cpu.shares
* cpuset.cpus
* memory.limit_in_bytes
* memory.memsw.limit_in_bytes
* memory.kmem.limit_in_bytes
* memory.kmem.tcp.limit_in_bytes

== Building ==

=== Dependencies ===

The following software needs to be installed on your system:

* iproute2 >= 3.0.0 (runtime only)
* libcgroup >= 0.38

=== Download ===

You can get the latest released version from [[Download/vzctl/{{Latest vzctl}}#sources]] or directly from [[download:utils/vzctl/current/src/]].

If you are living on the bleeding edge, get vzctl sources from git. Then run autogen.sh to recreate auto* files:

git clone git://git.openvz.org/pub/vzctl
cd vzctl
./autogen.sh

=== Compile ===

Usual ./confi

t makes sense to add <code>--without-ploop</code> (unless you want ploop compiled it) because otherwise you will need ploop lib headers.

$ ./configure --with-cgroup --without-ploop

Vzctl for upstream kernel

2012-09-13T13:55:43Z

Avagin: /* Networking */

Since version 4.0, vzctl tool can be used with upstream (non-OpenVZ) Linux kernels (that essentially means any recent 3.x kernel). At the moment, it provides just basic functionality.
It is currently possible to create and start a container with the same steps as one would use for a normal OpenVZ container. Other features may be present with limited functionality, while some are not present at all.

{{Warning|Running vzctl on upstream kernels is considered an experimental feature. See [[#Limitatons]] below.}}

== Installation ==

{{Note|This section describes installation for RPM-based distros. See [[#Building]] below if you want to compile vzctl from source.}}

First, set up OpenVZ yum repository. Download [[download:openvz.repo|openvz.repo]] file and put it to your <code>/etc/yum.repos.d/</code> repository,
and import OpenVZ GPG key used for signing RPM packages. This can be achieved by the following commands, as root:
<pre><nowiki>
wget -P /etc/yum.repos.d/ http://download.openvz.org/openvz.repo
rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ
</nowiki></pre>
In case you can not cd to /etc/yum.repos.d, it means either yum is not installed on your system, or yum version is too old.

Then, install vzctl-core package:

yum install vzctl-core

== Usage ==

For supported features, usage is expected to be the same as standard vzctl tool. See {{man|vzctl|8}} for more information.

=== Networking ===

Networking is available through the switches --netdev_add, --netif_add, and their respective deletion counterparts.
In this case [[Virtual Ethernet device]] is added in [[CT]].

One life hack may be useful while "vzctl enter" doesn't work.
If you use DHCP and don't know which an IP address is in CT, you can find it in /vz/root/[CTID]/var/log/message.

IP mode networking (--ipadd / --ipdel) is currently not supported.

== Limitations ==

The following vzctl commands are not working at all:
* <code>quotaon</code>/<code>quotaoff</code>/<code>quotainit</code> (vzquota-specific)
* <code>convert</code>, <code>compact</code>, <code>snapshot*</code> (ploop-specific)
* <code>console</code> (needs a virtual /dev/console, /dev/ttyN device)
* <code>enter</code>, <code>exec</code> and <code>runscript</code> (need pidns entering support)
* <code>chkpnt</code>, <code>restore</code> (currently need OpenVZ-kernel-specific checkpointing, [http://crui.org/ CRIU] will be supported later)

The following commands have severe limitations:
* <code>stop</code>. A container can be stopped from inside (say if one is connected to CT over ssh) in case the underlying kernel supports rebooting a PID namespace (> 3.4). Using vzctl, the "stop" command is not supported, unless accompanied by the --fast switch, which will simply forceably kill all processes in the container.

The following binaries are not ported to work on top of upstream kernel:
* vzlist
* vzcalc
* vzcfgvalidate
* vzcpucheck
* vzmemcheck
* vzmigrate
* vzeventd
* vzpid
* vzsplit
* vzubc

=== /proc and /sys ===
Software that depend on information supplied by the proc filesystem may not work correctly, since there is not a full solution for full /proc virtualization. For instance, /proc/stat is not yet virtualized, and top will show distorted values.

=== Resource management ===

Setting resources like <code>--ram</code> and <code>--cpuunits</code> work, but there their effect is dependent on what the current kernel supports, through the cgroups subsystem. When a particular cgroup file is present, it will be used. Currently, vzctl will search for the following files:
* cpu.cfs_quota_us
* cpu.shares
* cpuset.cpus
* memory.limit_in_bytes
* memory.memsw.limit_in_bytes
* memory.kmem.limit_in_bytes
* memory.kmem.tcp.limit_in_bytes

== Building ==

=== Dependencies ===

The following software needs to be installed on your system:

* iproute2 >= 3.0.0 (runtime only)
* libcgroup >= 0.38

=== Download ===

You can get the latest released version from [[Download/vzctl/{{Latest vzctl}}#sources]] or directly from [[download:utils/vzctl/current/src/]].

If you are living on the bleeding edge, get vzctl sources from git. Then run autogen.sh to recreate auto* files:

git clone git://git.openvz.org/pub/vzctl
cd vzctl
./autogen.sh

=== Compile ===

Usual ./confi

t makes sense to add <code>--without-ploop</code> (unless you want ploop compiled it) because otherwise you will need ploop lib headers.

$ ./configure --with-cgroup --without-ploop

Vzctl for upstream kernel

2012-09-13T13:55:12Z

Avagin: /* Networking */

Since version 4.0, vzctl tool can be used with upstream (non-OpenVZ) Linux kernels (that essentially means any recent 3.x kernel). At the moment, it provides just basic functionality.
It is currently possible to create and start a container with the same steps as one would use for a normal OpenVZ container. Other features may be present with limited functionality, while some are not present at all.

{{Warning|Running vzctl on upstream kernels is considered an experimental feature. See [[#Limitatons]] below.}}

== Installation ==

{{Note|This section describes installation for RPM-based distros. See [[#Building]] below if you want to compile vzctl from source.}}

First, set up OpenVZ yum repository. Download [[download:openvz.repo|openvz.repo]] file and put it to your <code>/etc/yum.repos.d/</code> repository,
and import OpenVZ GPG key used for signing RPM packages. This can be achieved by the following commands, as root:
<pre><nowiki>
wget -P /etc/yum.repos.d/ http://download.openvz.org/openvz.repo
rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ
</nowiki></pre>
In case you can not cd to /etc/yum.repos.d, it means either yum is not installed on your system, or yum version is too old.

Then, install vzctl-core package:

yum install vzctl-core

== Usage ==

For supported features, usage is expected to be the same as standard vzctl tool. See {{man|vzctl|8}} for more information.

=== Networking ===

Networking is available through the switches --netdev_add, --netif_add, and their respective deletion counterparts.
In this case [[Virtual Ethernet device]] is added in [[CT]].

One life hack may be useful while "vzctl enter" doesn't work. If you use DHCP and don't know which an IP address is in CT, you can find it in /vz/root/[CTID]/var/log/message.

IP mode networking (--ipadd / --ipdel) is currently not supported.

== Limitations ==

The following vzctl commands are not working at all:
* <code>quotaon</code>/<code>quotaoff</code>/<code>quotainit</code> (vzquota-specific)
* <code>convert</code>, <code>compact</code>, <code>snapshot*</code> (ploop-specific)
* <code>console</code> (needs a virtual /dev/console, /dev/ttyN device)
* <code>enter</code>, <code>exec</code> and <code>runscript</code> (need pidns entering support)
* <code>chkpnt</code>, <code>restore</code> (currently need OpenVZ-kernel-specific checkpointing, [http://crui.org/ CRIU] will be supported later)

The following commands have severe limitations:
* <code>stop</code>. A container can be stopped from inside (say if one is connected to CT over ssh) in case the underlying kernel supports rebooting a PID namespace (> 3.4). Using vzctl, the "stop" command is not supported, unless accompanied by the --fast switch, which will simply forceably kill all processes in the container.

The following binaries are not ported to work on top of upstream kernel:
* vzlist
* vzcalc
* vzcfgvalidate
* vzcpucheck
* vzmemcheck
* vzmigrate
* vzeventd
* vzpid
* vzsplit
* vzubc

=== /proc and /sys ===
Software that depend on information supplied by the proc filesystem may not work correctly, since there is not a full solution for full /proc virtualization. For instance, /proc/stat is not yet virtualized, and top will show distorted values.

=== Resource management ===

Setting resources like <code>--ram</code> and <code>--cpuunits</code> work, but there their effect is dependent on what the current kernel supports, through the cgroups subsystem. When a particular cgroup file is present, it will be used. Currently, vzctl will search for the following files:
* cpu.cfs_quota_us
* cpu.shares
* cpuset.cpus
* memory.limit_in_bytes
* memory.memsw.limit_in_bytes
* memory.kmem.limit_in_bytes
* memory.kmem.tcp.limit_in_bytes

== Building ==

=== Dependencies ===

The following software needs to be installed on your system:

* iproute2 >= 3.0.0 (runtime only)
* libcgroup >= 0.38

=== Download ===

You can get the latest released version from [[Download/vzctl/{{Latest vzctl}}#sources]] or directly from [[download:utils/vzctl/current/src/]].

If you are living on the bleeding edge, get vzctl sources from git. Then run autogen.sh to recreate auto* files:

git clone git://git.openvz.org/pub/vzctl
cd vzctl
./autogen.sh

=== Compile ===

Usual ./confi

t makes sense to add <code>--without-ploop</code> (unless you want ploop compiled it) because otherwise you will need ploop lib headers.

$ ./configure --with-cgroup --without-ploop

VPN via the TUN/TAP device

2011-08-18T11:59:45Z

Avagin: Someone joked about net_admin. Do it never, it's security hole.

This article describes how to use VPN via the TUN/TAP device inside a [[container]].

== Kernel TUN/TAP support ==
OpenVZ supports VPN inside a container via kernel TUN/TAP module and device.
To allow container #101 to use the TUN/TAP device the following should be done:

Make sure the '''tun''' module has been already loaded on the [[hardware node]]:
lsmod | grep tun

If it is not there, use the following command to load '''tun''' module:
modprobe tun

To make sure that '''tun''' module will be automatically loaded on every reboot you can also add it or into <code>/etc/modules.conf</code> (on RHEL see <code>/etc/sysconfig/modules/</code> directory).

== Granting container an access to TUN/TAP ==
Allow your container to use the tun/tap device by running the following commands on the host node:

vzctl set 101 --devnodes net/tun:rw --save

== Configuring VPN inside container ==
After the configuration steps above are done it is possible to use VPN software working with TUN/TAP inside
container just like on a usual standalone Linux box.

The following software can be used for VPN with TUN/TAP:
* Tinc (http://tinc-vpn.org)
* OpenVPN (http://openvpn.net)
* Virtual TUNnel (http://vtun.sourceforge.net)

== Reaching hosts behind VPN container ==
In order to reach hosts behind VPN container you must configure it to use a VETH interface instead a VENET one, at least with an OpenVPN server.

With a VENET interface you will only reach the VPN container.

To use a VETH device follow [[Veth]] article.

If you insist on using a VENET interface and need to reach hosts behind the OpenVPN VE then you can use source NAT. You need to mangle source packets so that they appear to originate from the OpenVPN server VE.

== Tinc problems ==

Using the default venet0:0 interface on the container, tinc seems to have problems as it complains the port 655 is already used on 0.0.0.0.

Netstat shows that the port 655 is available:

<pre>
root@132 / [3]# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost.localdom:8001 *:* LISTEN
tcp 0 0 *:2223 *:* LISTEN
tcp6 0 0 [::]:2223 [::]:* LISTEN
udp6 0 0 [::]:talk [::]:*
udp6 0 0 [::]:ntalk [::]:*
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 4831020 /var/run/uml-utilities/uml_switch.ctl
</pre>

Starting the Tincd daemon where it complains that port 655 is not available:

<pre>
root@132 / [4]# tincd -n myvpn
root@132 / [5]# tail -f /var/log/syslog
Jul 26 14:08:01 132 /USR/SBIN/CRON[15159]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 26 14:37:42 132 -- MARK --
Jul 26 14:57:42 132 -- MARK --
Jul 26 15:08:01 132 /USR/SBIN/CRON[15178]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 26 15:11:23 132 tinc.myvpn[15139]: Got TERM signal
Jul 26 15:11:23 132 tinc.myvpn[15139]: Terminating
Jul 26 15:11:37 132 tinc.myvpn[15191]: tincd 1.0.8 (Aug 14 2007 13:51:23) starting, debug level 0
Jul 26 15:11:37 132 tinc.myvpn[15191]: /dev/net/tun is a Linux tun/tap device (tun mode)
Jul 26 15:11:37 132 tinc.myvpn[15191]: Can't bind to 0.0.0.0 port 655/tcp: Address already in use
Jul 26 15:11:37 132 tinc.myvpn[15191]: Ready
^C
root@132 / [6]#
</pre>

An echo to Bindv6only (see [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440150 discussion here]) seems to resolve the problem:

<pre>
root@132 / [12]# echo 1 > /proc/sys/net/ipv6/bindv6only
</pre>

Or put in your /etc/sysctl.conf file:

<pre>
net.ipv6.bindv6only = 1
</pre>

Then apply the changes with:

<pre>
root@132 / [14]# sysctl -p
</pre>

== The tunctl problem ==
Unfortunately, you are limited to [http://forum.openvz.org/index.php?t=msg&th=4280&goto=22066&#msg_22066 non-persistent tunnels inside the VEs]:

<pre>
# tunctl
enabling TUNSETPERSIST: Operation not permitted
</pre>

Get a patched tunctl [https://github.com/xl0/uml-utilities here], and run it with the -n option. It will create a non-persistent tun device and sleep instead of terminating, to keep the device from deletion. To remove the tunnel, kill the tunctl process.

== Troubleshooting ==
If NAT is needed within the VE, this error will occur on attempts to use NAT:

# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j MASQUERADE
iptables v1.4.3.2: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

The solution is given here:

http://kb.parallels.com/en/5228

Also see page 69-70 of:

http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf

Note that the above steps do not solve the problem if a gentoo VE sits on a Centos HN; it's still an unsolved mystery.

== External links ==
* [http://vtun.sourceforge.net Virtual TUNnel]
* [http://openvpn.net OpenVPN]
* [http://tinc-vpn.org Tinc]
* [http://openvpn.net/index.php/access-server/howto-openvpn-as/186-how-to-run-access-server-on-a-vps-container.html How to run OpenVPN Access Server in OpenVZ]
* [http://kb.parallels.com/en/696 Parallels KB#696: Is VPN via the TUN/TAP device supported inside a Container?]
[[Category: HOWTO]]
[[Category: Networking]]