OpenVZ Virtuozzo Containers Wiki - User contributions [en]

UBC systemwide configuration

2009-07-27T05:34:51Z

Poige: Made "x86" mention clearer

{{UBC toc}}

The [[UBC consistency check]] article discussed validation of [[UBC]] configuration for a single container. This article discusses checks that the UBC configuration of the
'''whole''' system is '''valid'''.

Configurations where resources allowed for containers exceed system
capacity<ref>More precisely, configurations with excessive
overcommitment, as explained below.</ref> are not valid
and dangerous from stability point of view.
They may result in abnormal termination of the applications,
bad responsiveness of the system and, sometimes, system hangs.
Whereas the configuration validation discussed in [[UBC consistency check]]
addressed application functionality,
the validation considered in this section is aimed at security and stability
of the whole system.

The best way to make sure that the configuration of the whole system
is valid is to run periodic automatic checks, based on the formulae described
below.

== Resource utilization and commitment level ==

Several resources of the whole system (such as RAM) are discussed below
in terms of '''utilization''' and '''commitment level'''.

'''Utilization''' shows the amount of resources consumed by all
containers at the given time.
In general, low utilization values mean that the system is under-utilized.
Often, it means that the system is capable of supporting more containers
if the existing containers continue to maintain
the same load and resource consumption level.
High utilization values (in general, more than <code>1</code>)
mean the the system is overloaded and the service level
of the containers is degraded.

'''Commitment level''' shows how much resources are “promised” to the existing
containers. Low commitment levels mean that the system
is capable of supporting more containers.
Commitment levels more than <code>1</code> mean that the
containers are promised more resources
than the system has, and in this case the system is said to be
overcommitted.
If the system runs a lot of containers,
it is usually acceptable to have some overcommitment, because it is unlikely that all containers will request resources at the same time.
However, higher commitment levels (as discussed below for each resource
individually) will cause containerss to experience failures to
allocate and use the resources promised to them.

== “Low memory” (x86_32 specific) ==
Because of specifics of architecture of Intel's x86 processors, the RAM of the
computer can't be used uniformly.
The most important memory area is so called “low memory”, a part of memory
residing at lower addresses and directly accessible by the kernel.
For current Linux kernels, the size of low memory area is 832MB
(or, if the computer has less RAM than 832MB, the size of the RAM).

Note that 64-bit kernels (i.e. x86_64, ia64 etc.) can access all memory
directly and are not using “low memory” area.
=== Utilization ===
The lower bound estimation of low memory utilization is

<math>
\frac{\displaystyle\sum_{all\ containers}
(kmemsize_{cur}+allsocketbuf_{cur})}
{0.4\cdot\min(RAM\ size, {\rm 832MB})}\rm,
</math>

where

<math>
allsocketbuf=tcprcvbuf+tcpsndbuf+dgramrcvbuf+othersockbuf\rm.
</math>

Utilization of low memory below <math>1</math> is normal.
Utilization above <math>1</math> is not safe, and utilization above <math>2</math>
is dangerous is very likely to cause bad system responsiveness,
application stalls for seconds or more and termination of some applications.

=== Commitment level ===
The commitment level can be computed as

<math>
\frac{\displaystyle\sum_{all\ containers}
(kmemsize_{lim}+allsocketbuf_{lim})}
{0.4\cdot\min(RAM\ size, {\rm 832MB})}\rm.
</math>

Commitment levels below <math>1</math> are normal.
Levels between <math>1</math> and <math>1.2</math> are usually acceptable for systems with about
100 containers.
Systems with more containers may have the commitment level
increased, to about <math>1.5</math>—<math>2</math> for 400 containers.
Higher commitment levels for this resource are not recommended,
because the consequences of exceeding the low memory capacities
are severe and affect the whole system and all the containers.

== Total RAM ==
This subsection discusses usage of the whole RAM and its utilization.
Usage of swap space and the sum of used RAM and swap space are discussed
below in subsection [[{{PAGENAME}}#Memory and swap space|Memory and swap space]].

Current version of OpenVZ can't guarantee availability of certain
amount of memory (in opposite to the sum of memory and swap space),
so the commitment level is not applicable to the total RAM.
Such guarantees will be implemented in future versions.

=== Utilization ===

The amount of RAM consumed by all containers can be computed as

<math>
\sum_{all\ containers}
(physpages_{cur}\cdot4096+kmemsize_{cur}+allsocketbuf_{cur})\rm.
</math>

The difference between memory usage shown by <code>free(1)</code>
or <code>/proc/meminfo</code> and the total amount of RAM consumed by
containers is the memory used by system daemons
and different caches.

The memory utilization can be computed as

<math>
\frac{\displaystyle\sum_{all\ containers}
(physpages_{cur}\cdot4096+
kmemsize_{cur}+allsocketbuf_{cur})}
{RAM\ size}\rm.
</math>

Utilization levels from <math>0.8</math> to <math>1</math> are normal.
Lower utilization means that the system is under-utilized, and,
if other system resources and their commitment levels permit,
the system can host more containers.
By the nature of the accounting of <code>physpages</code> and other parameters,
total RAM utilization can't be bigger than <math>1</math>.

== Memory and swap space ==
The main resource of the computer determining the amount of memory
applications can use is the sum of RAM and swap sizes.
If the total size of the used memory exceeds the RAM size,
Linux kernel moves some data to swap and and loads it back when the
application needs it.
More frequently used data tends to stay in RAM, less frequently used
data spends more time in swap.

Swap-in and swap-out activity reduces the system performance to some extent.
However, if this activity is not excessive, the performance decrease is not
very noticeable. On the other hand, the benefits of using swap space are
quite big, allowing to increase the number of containers in the
system about 2 times.

Swap space is essential for handling system load bursts.
System with enough swap just slows down at high load bursts,
whereas the system without swap reacts to high load bursts by refusing
memory allocations (causing applications to refuse to accept clients or
terminate) and by direct killing of some applications.
Additionally, the presence of swap space helps the system to better
balance memory and move data between “low memory” and the rest of the RAM.

In all OpenVZ installations it is strongly recommended
to have swap of size not less than the RAM size.

Also, it is not recommended to create swap space of the size
of more than 4 times RAM size because of performance degradation
related to swap-in and swap-out activity.
That is, the system should be configured so that
<math>RAM\ size \le swap\ size \le 4\cdot RAM\ size\rm.</math>
The optimal configuration is when swap size is twice more than the RAM size.

=== Utilization ===
<math>
\frac{\displaystyle\sum_{all\ containers}
(oomguarpages_{cur}\cdot4096+
kmemsize_{cur}+allsocketbuf_{cur})}
{RAM\ size + swap\ size}\rm.
</math>

The normal utilization of memory plus swap ranges between
<math>\frac{RAM\ size}{RAM\ size + swap\ size}</math>
and
<math>\frac{RAM\ size + \frac12swap\ size}{RAM\ size + swap\ size}.</math>

Lower utilization means that the system memory is under-utilized
at the moment of checking the utilization.
Higher utilization is likely to cause gradual performance degradation because
of swap-in and swap-out activity and is a sign of overloading of the system.

=== Commitment level ===
<math>
\frac{\displaystyle\sum_{all\ containers}
(oomguarpages_{bar}\cdot4096+
kmemsize_{lim}+allsocketbuf_{lim})}
{RAM\ size + swap\ size}\rm.
</math>

The normal commitment level is about <math>0.8</math>—<math>1</math>.

Commitment levels more than <math>1</math> means that the containers are
guaranteed more memory than the system has.
Such overcommitment is strongly not recommended, because in that case
if all the memory is consumed, random applications, including the ones
belonging to the host system, may be killed and the system may become
inaccessible by <code>ssh(1)</code> and lose other important functionality.

It is better to guarantee containers less and have less commitment
levels than to accidentally overcommit the system by memory plus swap.
If the system has spare memory and swap, containers will
transparently be able to use the memory and swap above their guarantees.
Guarantees given to containers should not be big, and it is normal
if memory and swap usage for some containers stays above their
guarantee.
It is also normal to give guarantees only to containers with
preferred service.
But administrators should not guarantee container more
than the system actually has.

== Allocated memory ==

This subsection considers standard memory allocations made by
applications in the container.
The allocations for each container are controlled by
two parameters: <code>vmguarpages</code> and <code>privvmpages</code>,
discussed in sections FIXME.

Allocated memory is a more “virtual” system resource than the RAM or RAM
plus swap size.
Applications can allocate memory but start to use it only later, and
the amount of system's free memory will decrease only at the moment of the
use.
The sum of allocated memory size of all containers is an estimation
of how much physical memory will be used when (and if) all applications
claim the allocated memory.

=== Utilization ===
<math>
\frac{\displaystyle\sum_{all\ containers}
(privvmpages_{cur}\cdot4096+
kmemsize_{cur}+allsocketbuf_{cur})}
{RAM\ size + swap\ size}\rm.
</math>

This utilization level is the ratio of the amount of allocated memory
to the capacity of the system.

Low utilization level means that the system can support more
containers, if other resources permit.
High utilization levels may, but doesn't necessarily mean that
the system is overloaded.
As it was explaned above, not all applications use all the allocated memory,
so this utilization level may exceed <math>1</math>.

Computing this utilization level is useful for comparing
it with the commitment level and the level of memory allocation restrictions,
discussed below, to configure memory allocation restrictions
for the container.

=== Commitment level ===
Allocation guarantee commitment level

<math>
\frac{\displaystyle\sum_{all\ containers}
(vmguarpages_{bar}\cdot4096+
kmemsize_{lim}+allsocketbuf_{lim})}
{RAM\ size + swap\ size}
</math>

is the ratio of the memory space guaranteed to be available for
allocations to the capacity of the system.
Similarly to the commitment level of memory plus swap space (as discussed
in subsection [[{{PAGENAME}}#Memory and swap space|Memory and swap space]]),
this level should be kept below <math>1</math>.
If the level is above <math>1</math>, it significantly increases the chances of
applications to be killed instead of be notified in case the system
experiences a memory shortage.

It's better to provide lower guarantees than accidently guarantee more than
the system has, because containers are allowed to allocated memory
above their guarantee if the system is not tight on memory.
It is also normal to give guarantees only to containers with
preferred service.

== Limiting memory allocations ==
In addition to providing allocation guarantees, it is possible
to impose restrictions on the amount of memory allocated by
containers.

If a system has multiple containers,
it is important to make sure that for each container

<math>privvmpages_{lim}\cdot4096 \le 0.6\cdot {RAM\ size}\rm.</math>

If this condition is not satisfied, a single container may easily
cause an excessive swap-out and very bad performance of the whole system.
Usually, for each container <code>privvmpages</code> limitations are
to values much less than the size of the RAM.

The resource control parameters should be configured in a way,
so that in case of memory shortage applications are given chance
to notice the shortage and exit gracefully, instead of being terminated
by the kernel.
For this purpose, it is recommended to maintain reasonable
total level of memory allocation restrictions, computed as

<math>
\frac{\displaystyle\sum_{all\ containers}
(privvmpages_{lim}\cdot4096+
kmemsize_{lim}+allsocketbuf_{lim})}
{RAM\ size + swap\ size}\rm.
</math>

This number shows how much memory applications are allowed to allocate
in comparison with the capacity of the system.

In practice, a lot of applications do not use the memory very efficiently
and, sometimes, allocated memory will never be used later.
For example, Apache Web server at start time it allocates about
20–30%% more memory that it will ever use.
Some multi-threaded applications are especially bad at using their memory,
and their rate of allocated to used memory may happen to be 1000%.

The bigger the level of memory allocation restrictions,
the more chances are that applications will be killed instead
of getting an error on next memory allocation in case
the system experiences memory shortage.
The levels ranging in <math>1.5</math>–<math>4</math> can be considered acceptable.
Administrators can find experimentally the optimal setting for their load,
basing on the frequency of messages “Out of Memory: killing process”
in system logs, saved by <code>klogd(8)</code> and <code>syslogd(8)</code>.
However, for stability-critical applications, it's better to keep
the level not exceeding <math>1</math>.

<references/>

Physical to container

2008-08-03T19:24:14Z

Poige: /* PHP not serving pages / random issues */ — 1777 is the right /tmp's permission mode to go with

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

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

To make things easier you may like to first follow the basic instructions elsewhere and create a dummy container based on the same Linux distribution you want to migrate. That way you can take that dummy as a template and then copy to your new migrated container and modify. You can later discard this dummy.

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

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

Hint: Now comes the dummy container handy mentioned above: Simply copy the xxx.conf file of the dummy to your new yyy.conf and modify it.

== Copying the data ==

Copy all your data from the machine to an OpenVZ box. Say you'll be using container 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 container 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 container 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.

If you copied from the dummy container then this step is already accomplished.

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

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 container is a bit different to a real physical server, you have to edit some files inside your new container.

=== /etc/inittab ===
A container 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 container's root filesystem (<code>/</code>) is mounted not from the container itself, but rather from the host system. That leaves <code>/etc/mtab</code> in container 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 container.

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 container, /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) container:
vzctl exec 123 mount -t devpts none /dev/pts

=== /dev ===

==== Introduction: static /dev ====
In order for container to work, some nodes should be present in container's <code>/dev</code><code></code>. For modern distributions, udev is taking care of it. For a variety of reasons udev doesn't make much sense in a container, 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 <code>tmpfs</code> — this will not work in case of static <code>/dev</code>. So what you need to do is find out where <code>/dev</code> is being mounted on <code>tmpfs</code> and remove this. This is highly distribution-dependent; please add info for your distro here.

For Suse 11.0, It is found in /etc/init.d/boot

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

Please pay attention to the access permissions of the device files being created: a default file mode for newly created files is affected by <code>umask</code> ([[w:umask]]). You can use --mode option for <code>mknod</code> to set the desired permissions.

Hint:
Now comes the dummy container handy mentioned above: Simply copy the entire /dev directory of the dummy to your new migrated container - worked in my case at least with Debian Etch.

==== tty device nodes ====

In order for vzctl enter to work, a container 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 --mode 666 /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 --mode 666 /vz/private/123/dev/null c 1 3

==== /dev/urandom ====
Check that /dev/urandom exists. If it does not, create with:
mknod --mode 444 /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 container)
* clock (no clock setting is required/allowed in container)
* consolefont (container does not have a console)
* hdparm (container does not have real hard drives)
* klogd (unless you use iptables to LOG some packets)
* keymaps (container does not have a real keyboard)
* kudzu (container does not have real hardware)
* lm_sensors (container does not have access to hardware sensors)
* microcodectl (container can not update CPU microcode)
* netplugd (container 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/{CTID}/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 container ==

Try to start your new container:

vzctl start 123

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

== Troubleshooting ==

===PHP not serving pages / random issues===

Make sure that /tmp and /var/tmp are created if you rsynced over your data and that they have proper permissions

mkdir tmp
chmod 1777 tmp

=== Can't enter container ===

If you can not enter your container (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 container's startup scripts. On some distros, you need to have the appropriate line in container's /etc/fstab.

In Fedora, try commenting out any '''udev''' entries in /vz/private/{CTID}/etc/rc.sysinit
vi /vz/private/{CTID}/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 ==
{{Note|please add your line to the bottom of this list, and do not forget to sign it using <code><nowiki>--~~~~</nowiki></code>}}

* 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]] 16:16, 23 March 2007 (EST)
* Centos 4.4 with apache2, SVN, TRAC, etc. --[[User:bitherder|bitherder]] 23:38, 26 February 2008 (EST)
* Centos 4.6 with apache2, Tomcat 5.0.x, postgresql, etc on CentOS 5.1 64bit Host --[[User:laslos|laslos]] 17:35, 10 March 2008 (EST)
* Debian Etch with apache2 etc... on CentOS 4.6 Host --[[User:laslos|laslos]] 19:46, 10 March 2008 (EST)
* Debian 1:3.3.5-13 with apache2, PHP, etc. --[[User:Spawrks|spawrks]] 23:36, 10 April 2008 (EST)
* Debian Etch with apache2, MySQL, etc. --[[User:Zhafrance|zhafrance]] 16:29, 20 April 2008 (EST)
* Debian Etch i386 with apache2, MySQL, etc. --[[User:geejay|geejay]] 17:29, 26 May 2008 (GMT)
* Centos 4.6 with apache2, MySQL, Qmail etc. --[[User:Bharathchari|Bharathchari]] 08:06, 13 June 2008 (EDT)
* Centos 4.6 with cPanel/WHM (Apache2, Mysql, Exim, etc) --[[User:Zccopwrx|Zccopwrx]] 08:16, 30 July 2008 (EDT)
[[Category:HOWTO]]

Virtual network device

2008-08-03T19:19:12Z

Poige: typo fix

Virtual network device (<code>venet</code>) is the default network device for a [[container]]. This network device looks like a peer-to-peer connection between [[container]] and the [[CT0|host system]]. It does packet switching based on IP header. This is a default network device for container (an alternative is [[veth]] device).

Venet device is created automatically on [[container]] start. Vzctl scripts set up an appropriate IP address and other settings on venet inside a container.

== Usage ==

== Kernel module ==
First of all, check that <code>vznetdev</code> module is loaded:
<pre>
# lsmod | grep vznetdev
</pre>

If it is not, load the module:
<pre>
# modprobe vznetdev
</pre>

You might want to check /etc/init.d/vz script to make sure the module gets loaded during startup.

=== Adding IP address to a container ===
<pre>
vzctl set <CTID> --ipadd <IP1>[,<IP2>,...] [--save]
</pre>

{{Note|This option is incremental, so IP addresses are added to already existing ones.}}

==== Example ====
<pre>
vzctl set 101 --ipadd 10.0.0.1 --save
</pre>
After executing this command IP address 10.0.0.1 will be added to container 101 and IP configuration will be saved to a container configuration file.

=== Removing IP address from a container ===
<pre>
vzctl set <CTID> --ipdel <IP1>[,<IP2>,...] [--save]
vzctl set <CTID> --ipdel all [--save]
</pre>

==== Example ====
<pre>
vzctl set 101 --ipdel 10.0.0.1
</pre>
After executing this command IP address 10.0.0.1 will be removed from container 101, but IP configuration will not be changed in container config file. And after container reboot IP address 10.0.0.1 will be assigned to this container again.

== See also ==
* [[Veth]]
* [[Differences between venet and veth]]

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