https://wiki.openvz.org/api.php?action=feedcontributions&feedformat=atom&user=MoseOpenVZ Virtuozzo Containers Wiki - User contributions [en]2026-06-10T02:15:58ZUser contributionsMediaWiki 1.31.1https://wiki.openvz.org/index.php?title=Debian_template_creation&diff=13336Debian template creation2013-01-19T15:51:37Z<p>Mose: /* Final cleanup */</p>
<hr />
<div>These are rough instructions of how to manually create basic Debian template cache, which can be used to create OpenVZ [[VE]]s based on Debian. <br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
* See also: <tt>/usr/share/doc/vzctl/README.Debian</tt> in the ''vzctl'' Debian package<br />
<br />
== Prerequisites ==<br />
<br />
{{Warning|if you want to use <code>ext4</code> file system for <code>/vz</code>, use <code>nodelalloc</code> option in <code>/etc/fstab</code>, otherwise it will crash. See {{Bug|1509}} and its duplicates for details.}}<br />
<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Squeeze (current Debian stable) ===<br />
<br />
debootstrap --arch i386 squeeze /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 squeeze /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Lenny (Debian oldstable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node enable packet forwarding to forward<br />
# packets between the HN network interfaces and venet.<br />
# Proxy arp is needed when CT is in a different subnet<br />
# or when using veth AND veth is not bridged to a HN<br />
# interface. When veth is bridged to a HN interface,<br />
# the CT handles its own arps.<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
On debian squeeze only the following worked for me (''confirmed''), because the standard template names in /etc/vz/conf have changed.<br />
sudo vzctl set 777 --applyconfig basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo OSTEMPLATE=\"debian-6.0\"' >> /etc/vz/conf/777.conf<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian squeeze main contrib<br />
deb http://security.debian.org squeeze/updates main contrib<br />
deb http://http.us.debian.org/debian squeeze-updates main<br />
## backports - ONLY IF YOU KNOW WHAT YOU DO<br />
# deb http://http.us.debian.org/debian-backports/ squeeze-backports main<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example — note that not all of those packages are installed by default in Debian Squeeze (although they were in earlier versions):<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig module-init-tools<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
For dependency-based boot sequence introduced with Squeeze type:<br />
<br />
update-rc.d-insserv -f klogd remove<br />
update-rc.d-insserv -f quotarpc remove<br />
update-rc.d-insserv -f exim4 remove<br />
update-rc.d-insserv -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze. See the section below. }}<br />
<br />
=== Fix SSH host keys in Squeeze when using dependency-based booting ===<br />
<br />
rm -f /etc/ssh/ssh_host_*<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
cat << EOF > /etc/init.d/ssh_gen_host_keys<br />
#!/bin/sh<br />
### BEGIN INIT INFO<br />
# Provides: Generates new ssh host keys on first boot<br />
# Required-Start: $remote_fs $syslog<br />
# Required-Stop: $remote_fs $syslog<br />
# Default-Start: 2 3 4 5<br />
# Default-Stop:<br />
# Short-Description: Generates new ssh host keys on first boot<br />
# Description: Generates new ssh host keys on first boot<br />
### END INIT INFO<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ""<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ""<br />
insserv -r /etc/init.d/ssh_gen_host_keys<br />
rm -f \$0<br />
EOF<br />
</source><br />
chmod a+x /etc/init.d/ssh_gen_host_keys<br />
insserv /etc/init.d/ssh_gen_host_keys<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-5.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-6.0-i386-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=13335Debian template creation2013-01-19T15:32:02Z<p>Mose: /* Setting VE OSTEMPLATE */</p>
<hr />
<div>These are rough instructions of how to manually create basic Debian template cache, which can be used to create OpenVZ [[VE]]s based on Debian. <br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
* See also: <tt>/usr/share/doc/vzctl/README.Debian</tt> in the ''vzctl'' Debian package<br />
<br />
== Prerequisites ==<br />
<br />
{{Warning|if you want to use <code>ext4</code> file system for <code>/vz</code>, use <code>nodelalloc</code> option in <code>/etc/fstab</code>, otherwise it will crash. See {{Bug|1509}} and its duplicates for details.}}<br />
<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Squeeze (current Debian stable) ===<br />
<br />
debootstrap --arch i386 squeeze /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 squeeze /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Lenny (Debian oldstable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node enable packet forwarding to forward<br />
# packets between the HN network interfaces and venet.<br />
# Proxy arp is needed when CT is in a different subnet<br />
# or when using veth AND veth is not bridged to a HN<br />
# interface. When veth is bridged to a HN interface,<br />
# the CT handles its own arps.<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
On debian squeeze only the following worked for me (''confirmed''), because the standard template names in /etc/vz/conf have changed.<br />
sudo vzctl set 777 --applyconfig basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo OSTEMPLATE=\"debian-6.0\"' >> /etc/vz/conf/777.conf<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian squeeze main contrib<br />
deb http://security.debian.org squeeze/updates main contrib<br />
deb http://http.us.debian.org/debian squeeze-updates main<br />
## backports - ONLY IF YOU KNOW WHAT YOU DO<br />
# deb http://http.us.debian.org/debian-backports/ squeeze-backports main<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example — note that not all of those packages are installed by default in Debian Squeeze (although they were in earlier versions):<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig module-init-tools<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
For dependency-based boot sequence introduced with Squeeze type:<br />
<br />
update-rc.d-insserv -f klogd remove<br />
update-rc.d-insserv -f quotarpc remove<br />
update-rc.d-insserv -f exim4 remove<br />
update-rc.d-insserv -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze. See the section below. }}<br />
<br />
=== Fix SSH host keys in Squeeze when using dependency-based booting ===<br />
<br />
rm -f /etc/ssh/ssh_host_*<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
cat << EOF > /etc/init.d/ssh_gen_host_keys<br />
#!/bin/sh<br />
### BEGIN INIT INFO<br />
# Provides: Generates new ssh host keys on first boot<br />
# Required-Start: $remote_fs $syslog<br />
# Required-Stop: $remote_fs $syslog<br />
# Default-Start: 2 3 4 5<br />
# Default-Stop:<br />
# Short-Description: Generates new ssh host keys on first boot<br />
# Description: Generates new ssh host keys on first boot<br />
### END INIT INFO<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ""<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ""<br />
insserv -r /etc/init.d/ssh_gen_host_keys<br />
rm -f \$0<br />
EOF<br />
</source><br />
chmod a+x /etc/init.d/ssh_gen_host_keys<br />
insserv /etc/init.d/ssh_gen_host_keys<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-5.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-i386-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=12055Debian template creation2012-02-28T20:53:51Z<p>Mose: /* Preparing the HN network */</p>
<hr />
<div>These are rough instructions of how to manually create basic Debian template cache, which can be used to create OpenVZ [[VE]]s based on Debian. <br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
* See also: <tt>/usr/share/doc/vzctl/README.Debian</tt> in the ''vzctl'' Debian package<br />
<br />
== Prerequisites ==<br />
<br />
{{Warning|if you want to use <code>ext4</code> file system for <code>/vz</code>, use <code>nodelalloc</code> option in <code>/etc/fstab</code>, otherwise it will crash. See {{Bug|1509}} and its duplicates for details.}}<br />
<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Squeeze (current Debian stable) ===<br />
<br />
debootstrap --arch i386 squeeze /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 squeeze /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Lenny (Debian oldstable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node enable packet forwarding to forward<br />
# packets between the HN network interfaces and venet.<br />
# Proxy arp is needed when CT is in a different subnet<br />
# or when using veth AND veth is not bridged to a HN<br />
# interface. When veth is bridged to a HN interface,<br />
# the CT handles its own arps.<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
On debian squeeze only the following worked for me (''confirmed''), because the standard template names in /etc/vz/conf have changed.<br />
sudo vzctl set 777 --applyconfig basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo OSTEMPLATE=\"debian-5.0\"' >> /etc/vz/conf/777.conf<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian squeeze main contrib<br />
deb http://security.debian.org squeeze/updates main contrib<br />
deb http://http.us.debian.org/debian squeeze-updates main<br />
## backports - ONLY IF YOU KNOW WHAT YOU DO<br />
# deb http://http.us.debian.org/debian-backports/ squeeze-backports main<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example — note that not all of those packages are installed by default in Debian Squeeze (although they were in earlier versions):<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig module-init-tools<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
For dependency-based boot sequence introduced with Squeeze type:<br />
<br />
update-rc.d-insserv -f klogd remove<br />
update-rc.d-insserv -f quotarpc remove<br />
update-rc.d-insserv -f exim4 remove<br />
update-rc.d-insserv -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze. See the section below. }}<br />
<br />
=== Fix SSH host keys in Squeeze when using dependency-based booting ===<br />
<br />
rm -f /etc/ssh/ssh_host_*<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
cat << EOF > /etc/init.d/ssh_gen_host_keys<br />
#!/bin/sh<br />
### BEGIN INIT INFO<br />
# Provides: Generates new ssh host keys on first boot<br />
# Required-Start: $remote_fs $syslog<br />
# Required-Stop: $remote_fs $syslog<br />
# Default-Start: 2 3 4 5<br />
# Default-Stop:<br />
# Short-Description: Generates new ssh host keys on first boot<br />
# Description: Generates new ssh host keys on first boot<br />
### END INIT INFO<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ""<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ""<br />
insserv -r /etc/init.d/ssh_gen_host_keys<br />
rm -f \$0<br />
EOF<br />
</source><br />
chmod a+x /etc/init.d/ssh_gen_host_keys<br />
insserv /etc/init.d/ssh_gen_host_keys<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-5.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-i386-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Bridge_doesn%27t_forward_packets&diff=11999Bridge doesn't forward packets2012-02-19T05:02:49Z<p>Mose: /* Another Problem Case */</p>
<hr />
<div>Sometimes a bridge can mysteriously drop packets and not forward them.<br />
e.g. eyck user experienced a problem when some of the broadcasts were not<br />
delivered to container via the bridge.<br />
<br />
Original report and the thread: [http://forum.openvz.org/index.php?t=tree&th=4052& forum thread]<br />
<br />
== Simplest configuration ==<br />
<br />
Container #101 with veth interface (veth101.0) connected to eth0 physical interface via bridge.<br />
<br />
== Problem statement ==<br />
<br />
We faced a situation when some of the broadcast packets were not delivered to<br />
the container. Actually it could happen with any packets, not with the<br />
broadcasts only. But broadcasts are simpler and obviously should have been<br />
delivered to all the networking interfaces with no doubt.<br />
<br />
Using tcpdump we see that BOOTP/DHCP request is visible on br0 interface in<br />
the host system ([[CT0]]):<br />
15:21:52.258220 00:1b:d5:2c:bf:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 350: 0.0.0.0.68 > 255.255.255.255.67:<br />
BOOTP/DHCP, Request from 00:1b:d5:2c:bf:38, length 308<br />
15:21:52.287269 00:08:02:ac:36:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 172.17.8.254.67 > 255.255.255.255.68:<br />
BOOTP/DHCP, Reply, length 300<br />
<br />
However, eth0 inside the container received only 2nd packet with a BOOTP/DHCP reply and doesn't see the 1st one with the request itself:<br />
15:21:52.291145 00:08:02:ac:36:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 172.17.8.254.67 > 255.255.255.255.68:<br />
BOOTP/DHCP, Reply, length 300<br />
<br />
== Resolution ==<br />
<br />
It is not obvious at all, but bridges (though they have their own ebtables filters) do also call iptables FORWARD chain when forwarding packets between interfaces.<br />
Thus your FORWARD iptables rules should allow all the packets which are supposed to go through.<br />
<br />
in our case eyck had a default DROP policy on FORWARD and had to add:<br />
iptables -A FORWARD -d 255.255.255.255 -j ACCEPT<br />
to fix the issue.<br />
<br />
== Another Problem Case ==<br />
I had setup a bridge and got the same problem, but iptables was setup well. In my case the problem was lying in /proc/sys/net/bridge/.<br />
Everything inside had value "1". Changing them to "0" solved the problem. This stopped ARP and bridge packets from being<br />
passed through the FORWARD chain. These settings can be placed inside /etc/sysctl.conf (Debian) so that they are persistent.<br />
<br />
== Credits ==<br />
Many credits to Dariush Pietrzak, who patiently helped to debug this.<br />
<br />
[[Category:Troubleshooting]]<br />
[[Category:Networking]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11998Virtual Ethernet device2012-02-19T04:58:34Z<p>Mose: /* Automating the bridge */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vzbr0 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming that 192.168.0.0/24 is being used on your LAN, the following sections show how to configure a container for the LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
Since [[CT0]] is acting as a router between its physical network interface and the virtual network interface of the [[CT]], we need to add a route to the [[CT]] to direct traffic to the right destination.<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Bridging a [[CT]] interface to a [[CT0]] interface is the magic that allows the [[CT]] to be an independent host on the network with its own IP address, gateway, etc. [[CT0]] does not need any configuration for forwarding packets to the [[CT]] or performing proxy arp for the [[CT]].<br />
<br />
To manually configure a bridge and add devices to it, perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices and then follow these steps.<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
All routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
=== Automating the bridge ===<br />
The most convenient method is to automatically create the bridge at boot as a network interface, add the physical interface from [[CT0]] and then add the interface from each [[CT]] as it starts. All devices are connected to a virtual switch, and containers directly access the network just as any other host without additional configuration on [[CT0]].<br />
<br />
In Debian, configure the network interface on [[CT0]] to plug into a bridge in /etc/network/interfaces. The [[CT0]] physical device is added to the bridge as the "uplink" port to the physical network.<br />
<br />
The bridge forwarding delay is set to 0 seconds so that forwarding begins immediately when a new interface is added to a bridge. The default delay is 30 seconds, during which the bridge pauses all traffic to listen and figure out where devices are. This can interrupt services when a container is added to the bridge. If you aren't running the spanning tree protocol (off by default) and the bridge does not create a loop in your network, then there is no need for a forwarding delay.<br />
<pre><br />
iface eth0 inet manual<br />
<br />
auto vzbr0<br />
iface vzbr0 inet static<br />
bridge_ports eth0<br />
bridge_fd 0<br />
address 192.168.1.100<br />
netmask 255.255.255.0<br />
gateway 192.168.1.254<br />
</pre><br />
Follow the steps below for making a veth bridge persistent with the included script. That will automatically add each container to the bridge when it is started. Finally, specify vzbr0 as the bridge when adding the network interface to a container, as describe above. No configuration is needed on [[CT0]] for forwarding packets, proxy arp or additional routes. The interface in each [[CT]] can be configured as desired. Everything "just works" according to normal network interface configuration and default routing rules. Note that as discussed in the troubleshooting section below, bridged packets by default pass through the FORWARD iptables chain. Take care when adding rules to that table that bridged packets are not mistakenly blocked. This behavior can be disabled, if desired.<br />
<br />
=== Making a veth-device persistent ===<br />
These steps are no longer necessary, as the veth device is automatically created when the container is started. They remain here as a reference.<br />
<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl includes a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11997Virtual Ethernet device2012-02-19T04:51:32Z<p>Mose: /* Automating the bridge */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vzbr0 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming that 192.168.0.0/24 is being used on your LAN, the following sections show how to configure a container for the LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
Since [[CT0]] is acting as a router between its physical network interface and the virtual network interface of the [[CT]], we need to add a route to the [[CT]] to direct traffic to the right destination.<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Bridging a [[CT]] interface to a [[CT0]] interface is the magic that allows the [[CT]] to be an independent host on the network with its own IP address, gateway, etc. [[CT0]] does not need any configuration for forwarding packets to the [[CT]] or performing proxy arp for the [[CT]].<br />
<br />
To manually configure a bridge and add devices to it, perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices and then follow these steps.<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
All routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
=== Automating the bridge ===<br />
The most convenient method is to automatically create the bridge at boot as a network interface, add the physical interface from [[CT0]] and then add the interface from each [[CT]] as it starts. All devices are connected to a virtual switch, and containers directly access the network just as any other host without additional configuration on [[CT0]].<br />
<br />
In Debian, configure the network interface on [[CT0]] to plug into a bridge in /etc/network/interfaces. The [[CT0]] physical device is added to the bridge as the "uplink" port to the physical network.<br />
<br />
The bridge forwarding delay is set to 0 seconds so that forwarding begins immediately when a new interface is added to a bridge. The default delay is 30 seconds, during which the bridge pauses all traffic to listen and figure out where devices are. This can interrupt services when a container is added to the bridge. If you aren't running the spanning tree protocol (off by default) and the bridge does not create a loop in your network, then there is no need for a forwarding delay.<br />
<pre><br />
iface eth0 inet manual<br />
<br />
auto vzbr0<br />
iface vzbr0 inet static<br />
bridge_ports eth0<br />
bridge_fd 0<br />
address 192.168.1.100<br />
netmask 255.255.255.0<br />
gateway 192.168.1.254<br />
</pre><br />
Follow the steps below for making a veth bridge persistent with the included script. That will automatically add each container to the bridge when it is started. Finally, specify vzbr0 as the bridge when adding the network interface to a container, as describe above. No configuration is needed on [[CT0]] for forwarding packets, proxy arp or additional routes. The interface in each [[CT]] can be configured as desired. Everything "just works" according to normal network interface configuration and default routing rules. Note that as discussed in the troubleshooting section below, bridged packets pass through the FORWARD iptables chain. Take care when adding rules to that table that bridged packets are not mistakenly blocked.<br />
<br />
=== Making a veth-device persistent ===<br />
These steps are no longer necessary, as the veth device is automatically created when the container is started. They remain here as a reference.<br />
<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl includes a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11986Virtual Ethernet device2012-02-16T19:48:55Z<p>Mose: /* Simple configuration with virtual Ethernet device */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vzbr0 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming that 192.168.0.0/24 is being used on your LAN, the following sections show how to configure a container for the LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
Since [[CT0]] is acting as a router between its physical network interface and the virtual network interface of the [[CT]], we need to add a route to the [[CT]] to direct traffic to the right destination.<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Bridging a [[CT]] interface to a [[CT0]] interface is the magic that allows the [[CT]] to be an independent host on the network with its own IP address, gateway, etc. [[CT0]] does not need any configuration for forwarding packets to the [[CT]] or performing proxy arp for the [[CT]].<br />
<br />
To manually configure a bridge and add devices to it, perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices and then follow these steps.<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
All routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
=== Automating the bridge ===<br />
The most convenient method is to automatically create the bridge at boot as a network interface, add the physical interface from [[CT0]] and then add the interface from each [[CT]] as it starts. All devices are connected to a virtual switch, and containers directly access the network just as any other host without additional configuration on [[CT0]].<br />
<br />
In Debian, configure the network interface on [[CT0]] to be a bridge in /etc/network/interfaces.<br />
<pre><br />
iface eth0 inet manual<br />
<br />
auto vzbr0<br />
iface vzbr0 inet static<br />
bridge-ports eth0<br />
address 192.168.1.100<br />
netmask 255.255.255.0<br />
network 192.168.1.0<br />
broadcast 192.168.1.255<br />
gateway 192.168.1.254<br />
</pre><br />
Follow the steps below for making a veth bridge persistent with the included script. That will automatically add each container to the bridge when it is started. Finally, specify vzbr0 as the bridge when adding the network interface to a container, as describe above. No configuration is needed on [[CT0]] for forwarding packets, proxy arp or additional routes. The interface in each [[CT]] can be configured as desired. Everything "just works" according to normal network interface configuration and default routing rules.<br />
<br />
=== Making a veth-device persistent ===<br />
These steps are no longer necessary, as the veth device is automatically created when the container is started. They remain here as a reference.<br />
<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl includes a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11985Virtual Ethernet device2012-02-16T19:46:19Z<p>Mose: /* Adding veth to a CT */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vzbr0 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
Since [[CT0]] is acting as a router between its physical network interface and the virtual network interface of the [[CT]], we need to add a route to the [[CT]] to direct traffic to the right destination.<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Bridging a [[CT]] interface to a [[CT0]] interface is the magic that allows the [[CT]] to be an independent host on the network with its own IP address, gateway, etc. [[CT0]] does not need any configuration for forwarding packets to the [[CT]] or performing proxy arp for the [[CT]].<br />
<br />
To manually configure a bridge and add devices to it, perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices and then follow these steps.<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
All routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
=== Automating the bridge ===<br />
The most convenient method is to automatically create the bridge at boot as a network interface, add the physical interface from [[CT0]] and then add the interface from each [[CT]] as it starts. All devices are connected to a virtual switch, and containers directly access the network just as any other host without additional configuration on [[CT0]].<br />
<br />
In Debian, configure the network interface on [[CT0]] to be a bridge in /etc/network/interfaces.<br />
<pre><br />
iface eth0 inet manual<br />
<br />
auto vzbr0<br />
iface vzbr0 inet static<br />
bridge-ports eth0<br />
address 192.168.1.100<br />
netmask 255.255.255.0<br />
network 192.168.1.0<br />
broadcast 192.168.1.255<br />
gateway 192.168.1.254<br />
</pre><br />
Follow the steps below for making a veth bridge persistent with the included script. That will automatically add each container to the bridge when it is started. Finally, specify vzbr0 as the bridge when adding the network interface to a container, as describe above. No configuration is needed on [[CT0]] for forwarding packets, proxy arp or additional routes. The interface in each [[CT]] can be configured as desired. Everything "just works" according to normal network interface configuration and default routing rules.<br />
<br />
=== Making a veth-device persistent ===<br />
These steps are no longer necessary, as the veth device is automatically created when the container is started. They remain here as a reference.<br />
<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl includes a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11984Virtual Ethernet device2012-02-16T19:44:28Z<p>Mose: </p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
Since [[CT0]] is acting as a router between its physical network interface and the virtual network interface of the [[CT]], we need to add a route to the [[CT]] to direct traffic to the right destination.<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Bridging a [[CT]] interface to a [[CT0]] interface is the magic that allows the [[CT]] to be an independent host on the network with its own IP address, gateway, etc. [[CT0]] does not need any configuration for forwarding packets to the [[CT]] or performing proxy arp for the [[CT]].<br />
<br />
To manually configure a bridge and add devices to it, perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices and then follow these steps.<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
All routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
=== Automating the bridge ===<br />
The most convenient method is to automatically create the bridge at boot as a network interface, add the physical interface from [[CT0]] and then add the interface from each [[CT]] as it starts. All devices are connected to a virtual switch, and containers directly access the network just as any other host without additional configuration on [[CT0]].<br />
<br />
In Debian, configure the network interface on [[CT0]] to be a bridge in /etc/network/interfaces.<br />
<pre><br />
iface eth0 inet manual<br />
<br />
auto vzbr0<br />
iface vzbr0 inet static<br />
bridge-ports eth0<br />
address 192.168.1.100<br />
netmask 255.255.255.0<br />
network 192.168.1.0<br />
broadcast 192.168.1.255<br />
gateway 192.168.1.254<br />
</pre><br />
Follow the steps below for making a veth bridge persistent with the included script. That will automatically add each container to the bridge when it is started. Finally, specify vzbr0 as the bridge when adding the network interface to a container, as describe above. No configuration is needed on [[CT0]] for forwarding packets, proxy arp or additional routes. The interface in each [[CT]] can be configured as desired. Everything "just works" according to normal network interface configuration and default routing rules.<br />
<br />
=== Making a veth-device persistent ===<br />
These steps are no longer necessary, as the veth device is automatically created when the container is started. They remain here as a reference.<br />
<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl includes a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11981Virtual Ethernet device2012-02-16T18:51:31Z<p>Mose: /* Virtual Ethernet devices can be joined in one bridge */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
Since [[CT0]] is acting as a router between its physical network interface and the virtual network interface of the [[CT]], we need to add a route to the [[CT]] to direct traffic to the right destination.<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Bridging a [[CT]] interface to a [[CT0]] interface is the magic that allows the [[CT]] to be an independent host on the network with its own IP address, gateway, etc. [[CT0]] does not need any configuration for forwarding packets to the [[CT]] or performing proxy arp for the [[CT]].<br />
<br />
To manually configure a bridge and add devices to it, perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices and then follow these steps.<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
All routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11980Virtual Ethernet device2012-02-16T18:29:10Z<p>Mose: /* Add route in CT0 */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
Since [[CT0]] is acting as a router between its physical network interface and the virtual network interface of the [[CT]], we need to add a route to the [[CT]] to direct traffic to the right destination.<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11979Virtual Ethernet device2012-02-16T18:27:39Z<p>Mose: /* Configure device in CT */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces (Debian, see below) or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11978Virtual Ethernet device2012-02-16T18:25:06Z<p>Mose: /* Configure device in CT */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
The following steps show an example of a quick manual configuration of the [[CT]] network interface. Typically, you would configure the network settings in /etc/network/interfaces or however it is normally configured on your distribution. You can also comment or remove the configuration for venet0, if it exists, because that device will not be used.<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11977Virtual Ethernet device2012-02-16T18:16:13Z<p>Mose: /* Configure devices in CT0 */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] network interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11976Virtual Ethernet device2012-02-16T18:13:47Z<p>Mose: /* Configure devices in CT0 */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
The following steps are needed when the [[CT]] is '''not''' bridged to a [[CT0]] interface. That is because the [[CT]] is connected to a virtual network that is "behind" [[CT0]]. [[CT0]] must forward packets between its physical network interface and the virtual network interface where [[CT]] is located. The first step below to configure the interface is not necessary if the container has been started, since the device will have been initialized.<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11975Virtual Ethernet device2012-02-16T17:52:08Z<p>Mose: /* Removing veth from a CT */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11974Virtual Ethernet device2012-02-16T17:51:17Z<p>Mose: /* Removing veth from a CT */</p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]], and it is typically eth0.<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11973Virtual Ethernet device2012-02-16T17:50:05Z<p>Mose: </p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
A virtual Ethernet device consist of two Ethernet devices,<br />
one in [[CT0]] (e.g., vethN.0) and a corresponding one in CT (e.g., eth0) that are<br />
connected to each other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
The <code>vzethdev</code> module should be loaded. You can check it with the following commands.<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
The following steps to generate a MAC address are not necessary, since newer versions<br />
of vzctl will automatically generate a MAC address for you. These steps are provided<br />
in case you want to set a MAC address manually.<br />
<br />
You should use a random MAC address when adding a network interface to a container. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
There is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge. (See the reference to the vznetaddbr script below and persistent bridge configurations.)<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional. Missing parameters, except for bridge, are automatically generated, if not specified. This is the preferred method.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
If you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
If you want to specify the bridge and autogenerate the other values:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Virtual_Ethernet_device&diff=11972Virtual Ethernet device2012-02-16T17:32:56Z<p>Mose: </p>
<hr />
<div>'''Virtual Ethernet device''' is an Ethernet-like device that can be used<br />
inside a [[container]]. Unlike a [[venet]] network device, a [[veth]] device<br />
has a MAC address. Therefore, it can be used in more configurations. When veth<br />
is bridged to a [[CT0]] network interface (e.g., eth0), the container can act as an<br />
independent host on the network. The container's user can set up all of the networking<br />
himself, including IPs, gateways, etc.<br />
<br />
Virtual Ethernet device consist of two Ethernet devices --<br />
one in [[CT0]] and another one in CT. These devices are connected to each<br />
other. If a packet is sent to one device it will come out the other device.<br />
<br />
== Virtual Ethernet device usage ==<br />
<br />
=== Kernel module ===<br />
First of all, make sure the <code>vzethdev</code> module is loaded:<br />
<pre><br />
# lsmod | grep vzeth<br />
vzethdev 8224 0<br />
vzmon 35164 5 vzethdev,vznetdev,vzrst,vzcpt<br />
vzdev 3080 4 vzethdev,vznetdev,vzmon,vzdquota<br />
</pre><br />
<br />
In case it is not loaded, load it:<br />
<pre><br />
# modprobe vzethdev<br />
</pre><br />
<br />
=== MAC addresses ===<br />
In the below commands, you should use random MAC addresses. Do not use MAC addresses of real eth devices, because this can lead to collisions.<br />
<br />
MAC addresses must be entered in XX:XX:XX:XX:XX:XX format.<br />
<br />
YOU MAY NOT NEED TO GENERATE MAC ADDRESSES BY HAND BECAUSE vzctl --veth_add<br />
MAY GENERATE THEM AUTOMATICALLY AS NECESSARY.<br />
<br />
Nevertheless, there is a utility script available for generating MAC addresses: http://www.easyvmx.com/software/easymac.sh. It is to be used like this:<br />
<br />
chmod +x easymac.sh<br />
./easymac.sh -R<br />
<br />
=== Adding veth to a CT ===<br />
<br />
vzctl set <CTID> --netif_add <ifname>[,<mac>,<host_ifname>,<host_mac>,<bridge>]<br />
<br />
Here<br />
* <tt>ifname</tt> is the Ethernet device name in the CT<br />
* <tt>mac</tt> is its MAC address in the CT<br />
* <tt>host_ifname</tt> is the Ethernet device name on the host ([[CT0]])<br />
* <tt>host_mac</tt> is its MAC address on the host ([[CT0]])<br />
* <tt>bridge</tt> is an optional parameter which can be used in custom network start scripts to automatically add the interface to a bridge.<br />
<br />
{{Note|All parameters except <code>ifname</code> are optional and are automatically generated if not specified.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_add eth0 --save<br />
<br />
Or, if you want to specify everything:<br />
<br />
vzctl set 101 --netif_add eth0,00:12:34:56:78:9A,veth101.0,00:12:34:56:78:9B --save<br />
<br />
Or, if you want to specify the bridge and leave the other values autogenerated:<br />
<br />
vzctl set 101 --netif_add eth0,,,,vmbr1 --save<br />
<br />
=== Removing veth from a CT ===<br />
<br />
vzctl set <CTID> --netif_del <dev_name>|all<br />
<br />
Here<br />
* <code>dev_name</code> is the Ethernet device name in the [[CT]].<br />
<br />
{{Note|If you want to remove all Ethernet devices in CT, use <code>all</code>.}}<br />
<br />
Example:<br />
<br />
vzctl set 101 --netif_del eth0 --save<br />
<br />
== Common configurations with virtual Ethernet devices ==<br />
Module <tt>vzethdev</tt> must be loaded to operate with veth devices.<br />
<br />
=== Simple configuration with virtual Ethernet device ===<br />
<br />
Assuming you have 192.168.0.0/24 on your LAN, you will learn how to integrate a container in this LAN using veth.<br />
<br />
==== Start a CT ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure devices in CT0 ====<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/proxy_arp<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp<br />
</pre><br />
<br />
==== Configure device in CT ====<br />
<pre><br />
[host-node]# vzctl enter 101<br />
[ve-101]# /sbin/ifconfig eth0 0<br />
[ve-101]# /sbin/ip addr add 192.168.0.101 dev eth0<br />
[ve-101]# /sbin/ip route add default dev eth0<br />
</pre><br />
<br />
Notes:<br />
* Until you ifconfig eth0 it won't appear. When you do it will use the mac address netif_add added earlier<br />
* 192.168.0.101 is chosen to be an [[unrouteable private ip address]]. Where 101 reminds you that it is node 101.<br />
* The "ip route" tells all traffic to head to "device eth0"<br />
* In theory you could [[use dhcpd with OpenVZ]] and dhclient to pick up an DHCP address from your router instead of hardwiring it<br />
** http://openvz.org/pipermail/users/2005-November/000020.html<br />
<br />
==== Add route in [[CT0]] ====<br />
<br />
[host-node]# ip route add 192.168.0.101 dev veth101.0<br />
<br />
<br />
=== Using a directly routed IPv4 with virtual Ethernet device ===<br />
<br />
==== Situation ====<br />
Hardware Node (HN/CT0) has 192.168.0.1/24 with router 192.168.0.254.<br />
<br />
We also know that IPv4 10.0.0.1/32 is directly routed to 192.168.0.1 (this is called a ''fail-over IP'').<br />
<br />
We want to give this directly routed IPv4 address to a container (CT).<br />
<br />
==== Start container ====<br />
<br />
[host-node]# vzctl start 101<br />
<br />
==== Add veth device to CT ====<br />
<br />
[host-node]# vzctl set 101 --netif_add eth0 --save<br />
<br />
This allocates a MAC address and associates it with the host eth0 port.<br />
<br />
==== Configure device and add route in CT0 ====<br />
<br />
<pre><br />
[host-node]# ifconfig veth101.0 0<br />
[host-node]# ip route add 10.0.0.1 dev veth101.0<br />
</pre><br />
<br />
You can automatize this at VPS creation by using a mount script <tt>$VEID.mount</tt>.<br />
<br />
The problem here is that the ''veth'' interface appears in CT0 '''after''' VPS has started, therefore we cannot directly use the commands in the mount script. We launch a shell script (enclosed by { }) in background (operator '''&''') that waits for the interface to be ready and then adds the IP route.<br />
<br />
Contents of the mount script <tt>/etc/vz/conf/101.mount</tt>:<br />
<pre><br />
#!/bin/bash<br />
# This script source VPS configuration files in the same order as vzctl does<br />
<br />
# if one of these files does not exist then something is really broken<br />
[ -f /etc/vz/vz.conf ] || exit 1<br />
[ -f $VE_CONFFILE ] || exit 1<br />
<br />
# source both files. Note the order, it is important<br />
. /etc/vz/vz.conf<br />
. $VE_CONFFILE<br />
<br />
# Configure veth with IP after VPS has started<br />
{<br />
IP=X.Y.Z.T<br />
DEV=veth101.0<br />
while sleep 1; do<br />
/sbin/ifconfig $DEV 0 >/dev/null 2>&1<br />
if [ $? -eq 0 ]; then<br />
/sbin/ip route add $IP dev $DEV<br />
break<br />
fi<br />
done<br />
} &<br />
</pre><br />
<br />
==== Make sure IPv4 forwarding is enabled in CT0 ====<br />
<br />
<pre><br />
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding<br />
[host-node]# echo 1 > /proc/sys/net/ipv4/conf/veth101.0/forwarding<br />
</pre><br />
You can permanently set this by using <tt>/etc/sysctl.conf</tt>.<br />
<br />
==== Configure device in CT ====<br />
<br />
1. Configure IP address<br />
<br />
2. Add gateway<br />
<br />
3. Add default route<br />
<br />
<pre><br />
[ve-101]# /sbin/ifconfig eth0 10.0.0.1 netmask 255.255.255.255<br />
[ve-101]# /sbin/ip route add 192.168.0.1 dev eth0<br />
[ve-101]# /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
In a Debian container, you can configure this permanently by using <tt>/etc/network/interfaces</tt>:<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 10.0.0.1<br />
netmask 255.255.255.255<br />
up /sbin/ip route add 192.168.0.1 dev eth0<br />
up /sbin/ip route add default via 192.168.0.1<br />
</pre><br />
<br />
=== Virtual Ethernet device with IPv6 ===<br />
<br />
See the [[VEs and HNs in same subnets]] article.<br />
<br />
=== Virtual Ethernet devices can be joined in one bridge ===<br />
Perform steps 1 - 4 from Simple configuration chapter for several containers and/or veth devices<br />
<br />
==== Create bridge device ====<br />
<pre><br />
[host-node]# brctl addbr vzbr0<br />
</pre><br />
<br />
==== Add veth devices to bridge ====<br />
<pre><br />
[host-node]# brctl addif vzbr0 veth101.0<br />
...<br />
[host-node]# brctl addif vzbr0 veth101.n<br />
[host-node]# brctl addif vzbr0 veth102.0<br />
...<br />
...<br />
[host-node]# brctl addif vzbr0 vethXXX.N<br />
</pre><br />
<br />
==== Configure bridge device ====<br />
<pre><br />
[host-node]# ifconfig vzbr0 0<br />
</pre><br />
<br />
==== Add routes in [[CT0]] ====<br />
<pre><br />
[host-node]# ip route add 192.168.101.1 dev vzbr0<br />
...<br />
[host-node]# ip route add 192.168.101.n dev vzbr0<br />
[host-node]# ip route add 192.168.102.1 dev vzbr0<br />
...<br />
...<br />
[host-node]# ip route add 192.168.XXX.N dev vzbr0<br />
</pre><br />
<br />
Thus you'll have more convinient configuration, i.e. all routes to containers will be through this bridge and containers can communicate with each other even without these routes.<br />
<br />
<br />
<br />
<br />
=== Making a veth-device persistent ===<br />
According to http://bugzilla.openvz.org/show_bug.cgi?id=301 , a bug that stopped the veth device persistent was "Obsoleted now when --veth_add/--veth_del are introduced"<br />
<br />
See http://wiki.openvz.org/w/index.php?title=Virtual_Ethernet_device&diff=5990&oldid=5989#Making_a_veth-device_persistent for a workaround that used to be described in this section.<br />
<br />
That's it! At this point, when you restart the CT you should see a new line in the output, indicating that the interface is being configured and a new route being added. And you should be able to ping the host, and to enter the CT and use the network.<br />
<br />
=== Making a bridged veth-device persistent ===<br />
<br />
Like the above example, here it is how to add the veth device to a bridge in a persistent way. <br />
<br />
vzctl include a 'vznetaddbr' script, which makes use of the ''bridge'' parameter of the --netif_add switch.<br />
<br />
Just create /etc/vz/vznet.conf containing the following.<br />
<br />
<pre><br />
#!/bin/bash<br />
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"<br />
</pre><br />
<br />
The script uses 'vmbr0' as default bridge name when no bridge is specified.<br />
<br />
=== Virtual Ethernet devices + VLAN ===<br />
This configuration can be done by adding vlan device to the previous configuration.<br />
<br />
== See also ==<br />
* [[Virtual network device]]<br />
* [[Differences between venet and veth]]<br />
* [[Using private IPs for Hardware Nodes]]<br />
* Patch: [[Disable venet interface]]<br />
* Troubleshooting: [[Bridge doesn't forward packets]]<br />
<br />
== External links ==<br />
* [http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-radvd.html Linux IPv6 HOWTO, a chapter about radvd]<br />
* [http://sysadmin-ivanov.blogspot.com/2008/02/2-veth-with-2-bridges-on-openvz-at.html 2 veth with 2 bridges setup]<br />
<br />
[[Category: Networking]]<br />
[[Category: HOWTO]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=11967Debian template creation2012-02-14T18:38:50Z<p>Mose: /* Preparing the HN network */</p>
<hr />
<div>These are rough instructions of how to manually create basic Debian template cache, which can be used to create OpenVZ [[VE]]s based on Debian. <br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
* See also: <tt>/usr/share/doc/vzctl/README.Debian</tt> in the ''vzctl'' Debian package<br />
<br />
== Prerequisites ==<br />
<br />
{{Warning|if you want to use <code>ext4</code> file system for <code>/vz</code>, use <code>nodelalloc</code> option in <code>/etc/fstab</code>, otherwise it will crash. See {{Bug|1509}} and its duplicates for details.}}<br />
<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Squeeze (current Debian stable) ===<br />
<br />
debootstrap --arch i386 squeeze /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 squeeze /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Lenny (Debian oldstable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node enable packet forwarding to forward<br />
# packets between the HN network interfaces and venet.<br />
# Proxy arp is only needed when using veth AND veth is<br />
# not bridged to a HN interface. When veth is bridged<br />
# to a HN interface, the CT handles its own arps.<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
On debian squeeze only the following worked for me (''confirmed''), because the standard template names in /etc/vz/conf have changed.<br />
sudo vzctl set 777 --applyconfig basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo OSTEMPLATE=\"debian-5.0\"' >> /etc/vz/conf/777.conf<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian squeeze main contrib<br />
deb http://security.debian.org squeeze/updates main contrib<br />
deb http://http.us.debian.org/debian squeeze-updates main<br />
## backports - ONLY IF YOU KNOW WHAT YOU DO<br />
# deb http://http.us.debian.org/debian-backports/ squeeze-backports main<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example — note that not all of those packages are installed by default in Debian Squeeze (although they were in earlier versions):<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig module-init-tools<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
For dependency-based boot sequence introduced with Squeeze type:<br />
<br />
update-rc.d-insserv -f klogd remove<br />
update-rc.d-insserv -f quotarpc remove<br />
update-rc.d-insserv -f exim4 remove<br />
update-rc.d-insserv -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze. See the section below. }}<br />
<br />
=== Fix SSH host keys in Squeeze when using dependency-based booting ===<br />
<br />
rm -f /etc/ssh/ssh_host_*<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
cat << EOF > /etc/init.d/ssh_gen_host_keys<br />
#!/bin/sh<br />
### BEGIN INIT INFO<br />
# Provides: Generates new ssh host keys on first boot<br />
# Required-Start: $remote_fs $syslog<br />
# Required-Stop: $remote_fs $syslog<br />
# Default-Start: 2 3 4 5<br />
# Default-Stop:<br />
# Short-Description: Generates new ssh host keys on first boot<br />
# Description: Generates new ssh host keys on first boot<br />
### END INIT INFO<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ""<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ""<br />
insserv -r /etc/init.d/ssh_gen_host_keys<br />
rm -f \$0<br />
EOF<br />
</source><br />
chmod a+x /etc/init.d/ssh_gen_host_keys<br />
insserv /etc/init.d/ssh_gen_host_keys<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-5.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-i386-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=10704Debian template creation2011-07-23T11:18:01Z<p>Mose: /* Setting VE OSTEMPLATE */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
<br />
{{Warning|if you want to use <code>ext4</code> file system for <code>/vz</code>, use <code>nodelalloc</code> option in <code>/etc/fstab</code>, otherwise it will crash. See {{Bug|1509}} and its duplicates for details.}}<br />
<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Squeeze (current Debian stable) ===<br />
<br />
debootstrap --arch i386 squeeze /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 squeeze /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Lenny (Debian oldstable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
On debian squeeze only the following worked for me (''confirmed''), because the standard template names in /etc/vz/conf have changed.<br />
sudo vzctl set 777 --applyconfig basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo OSTEMPLATE=\"debian-5.0\"' >> /etc/vz/conf/777.conf<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian squeeze main contrib<br />
deb http://security.debian.org squeeze/updates main contrib<br />
deb http://http.us.debian.org/debian squeeze-updates main<br />
## backports - ONLY IF YOU KNOW WHAT YOU DO<br />
# deb http://http.us.debian.org/debian-backports/ squeeze-backports main<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example — note that not all of those packages are installed by default in Debian Squeeze (although they were in earlier versions):<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig module-init-tools<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
For dependency-based boot sequence introduced with Squeeze type:<br />
<br />
update-rc.d-insserv -f klogd remove<br />
update-rc.d-insserv -f quotarpc remove<br />
update-rc.d-insserv -f exim4 remove<br />
update-rc.d-insserv -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze. See the section below. }}<br />
<br />
=== Fix SSH host keys in Squeeze when using dependency-based booting ===<br />
<br />
rm -f /etc/ssh/ssh_host_*<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
cat << EOF > /etc/init.d/ssh_gen_host_keys<br />
#!/bin/sh<br />
### BEGIN INIT INFO<br />
# Provides: Generates new ssh host keys on first boot<br />
# Required-Start: $remote_fs $syslog<br />
# Required-Stop: $remote_fs $syslog<br />
# Default-Start: 2 3 4 5<br />
# Default-Stop:<br />
# Short-Description: Generates new ssh host keys on first boot<br />
# Description: Generates new ssh host keys on first boot<br />
### END INIT INFO<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
insserv -r /etc/init.d/ssh_gen_host_keys<br />
rm -f \$0<br />
EOF<br />
</source><br />
chmod a+x /etc/init.d/ssh_gen_host_keys<br />
insserv /etc/init.d/ssh_gen_host_keys<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-5.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-i386-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=10703Debian template creation2011-07-23T11:17:30Z<p>Mose: /* Setting VE config */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
<br />
{{Warning|if you want to use <code>ext4</code> file system for <code>/vz</code>, use <code>nodelalloc</code> option in <code>/etc/fstab</code>, otherwise it will crash. See {{Bug|1509}} and its duplicates for details.}}<br />
<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Squeeze (current Debian stable) ===<br />
<br />
debootstrap --arch i386 squeeze /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 squeeze /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Lenny (Debian oldstable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
On debian squeeze only the following worked for me (''confirmed''), because the standard template names in /etc/vz/conf have changed.<br />
sudo vzctl set 777 --applyconfig basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo OSTEMPLATE=\"debian-5.0\"' >> /etc/vz/conf/777.conf<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian squeeze main contrib<br />
deb http://security.debian.org squeeze/updates main contrib<br />
deb http://http.us.debian.org/debian squeeze-updates main<br />
## backports - ONLY IF YOU KNOW WHAT YOU DO<br />
# deb http://http.us.debian.org/debian-backports/ squeeze-backports main<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example — note that not all of those packages are installed by default in Debian Squeeze (although they were in earlier versions):<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig module-init-tools<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
For dependency-based boot sequence introduced with Squeeze type:<br />
<br />
update-rc.d-insserv -f klogd remove<br />
update-rc.d-insserv -f quotarpc remove<br />
update-rc.d-insserv -f exim4 remove<br />
update-rc.d-insserv -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze. See the section below. }}<br />
<br />
=== Fix SSH host keys in Squeeze when using dependency-based booting ===<br />
<br />
rm -f /etc/ssh/ssh_host_*<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
cat << EOF > /etc/init.d/ssh_gen_host_keys<br />
#!/bin/sh<br />
### BEGIN INIT INFO<br />
# Provides: Generates new ssh host keys on first boot<br />
# Required-Start: $remote_fs $syslog<br />
# Required-Stop: $remote_fs $syslog<br />
# Default-Start: 2 3 4 5<br />
# Default-Stop:<br />
# Short-Description: Generates new ssh host keys on first boot<br />
# Description: Generates new ssh host keys on first boot<br />
### END INIT INFO<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
insserv -r /etc/init.d/ssh_gen_host_keys<br />
rm -f \$0<br />
EOF<br />
</source><br />
chmod a+x /etc/init.d/ssh_gen_host_keys<br />
insserv /etc/init.d/ssh_gen_host_keys<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-5.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-i386-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9195Debian template creation2010-09-30T14:39:30Z<p>Mose: /* Final cleanup */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-5.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-5.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-i386-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9194Debian template creation2010-09-30T14:39:01Z<p>Mose: /* Checking if template cache works */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-5.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-5.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-amd65-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9193Debian template creation2010-09-30T14:38:43Z<p>Mose: /* Preparing for and packing template cache */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-5.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-5.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-5.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-amd65-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9192Debian template creation2010-09-30T14:37:12Z<p>Mose: /* Setting VE OSTEMPLATE */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-5.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-amd65-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9191Debian template creation2010-09-30T14:23:45Z<p>Mose: /* Final cleanup */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-amd65-minimal"<br />
If you use iptables, you might want to include additional modules in the list for IPTABLES in /etc/vz/vz.conf. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9190Debian template creation2010-09-30T14:21:49Z<p>Mose: /* Final cleanup */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
You might want to edit /etc/vz/vz.conf and change DEF_OSTEMPLATE to the name of the template you use most often so that you don't have to specify the template when creating a VE.<br />
DEF_OSTEMPLATE="debian-5.0-amd65-minimal"<br />
If you use iptables, you might want to include additional modules in the list. See ''man vzctl'' for a list of available modules.<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9189Debian template creation2010-09-30T14:03:44Z<p>Mose: /* Clean packages */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get --purge clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9188Debian template creation2010-09-30T13:59:45Z<p>Mose: /* Customizing the installation */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
A few things need to be done inside a newly created VE for it to become suitable for OpenVZ. Enter the VE to begin the configuration. Exporting the path is optional.<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9187Debian template creation2010-09-30T13:57:18Z<p>Mose: /* Set Debian repositories */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian lenny main contrib<br />
deb http://security.debian.org lenny/updates main contrib<br />
deb http://security.debian.org lenny/volatile main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9186Debian template creation2010-09-30T13:54:11Z<p>Mose: /* Creating /dev/ptmx */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exist, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian etch main contrib<br />
deb http://security.debian.org etch/updates main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9185Debian template creation2010-09-30T13:53:56Z<p>Mose: /* Creating /dev/ptmx */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
The ptmx character device should normally exists, but if it doesn't, create one.<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian etch main contrib<br />
deb http://security.debian.org etch/updates main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9184Debian template creation2010-09-30T13:34:55Z<p>Mose: /* Bootstrapping Debian */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>. You can use http or ftp in the URL.<br />
<br />
We use VE ID of 777 for this example, but it can be any unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
or<br />
debootstrap --arch amd64 lenny /vz/private/777 ftp://ftp.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Creating /dev/ptmx ===<br />
Before starting the VE we need a valide character ptmx device<br />
sudo mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian etch main contrib<br />
deb http://security.debian.org etch/updates main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=9165Debian template creation2010-09-22T13:12:30Z<p>Mose: </p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>.<br />
<br />
We use VE ID of 777 for this example; surely it can be any other unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{Note|if you use private IP for the VE, you might have to set up NAT as described in [[Using NAT for VE with private IPs]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian etch main contrib<br />
deb http://security.debian.org etch/updates main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
{{Note|This will not work using the dependency-based boot sequence introduced with Squeeze...}}<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debootstrap_from_foreign_version_or_distribution&diff=9146Debootstrap from foreign version or distribution2010-09-21T13:03:25Z<p>Mose: </p>
<hr />
<div>[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Ubuntu]]<br />
[[Category: Debian]]<br />
<br />
This procedure (for Debian, Ubuntu, and derivatives) is useful when need to create a template, and your host doesn't have that suite's script (in /usr/share/debootstrap/scripts). This situation can happen when your host and your next template are from different distributions, or when your host is an older version than the next template you want to create (for example, creating an Ubuntu 10.04 template in an Ubuntu 8.04 host).<br />
<br />
To do this, you need a computer to install a clean system or a virtual one with [http://www.qemu.org/ Qemu] or similar.<br />
<br />
'''Step 1: install a system with the distribution & version you want for template'''<br />
<br />
We will call it the "satellite system". You can do it also with another already installed computer with the same distribution & version you want. Also with a Live-CD with sufficient RAM memory available for a subsystem installation.<br />
<br />
'''Step 2: debootstrap''' (in satellite system)<br />
cd /tmp<br />
sudo apt-get install debootstrap<br />
mkdir newsystem<br />
# The parameter ''--variant=minbase'' is optional. You may want it to make a minimal template.<br />
sudo debootstrap --variant=minbase $(lsb_release -cs) newsystem<br />
<br />
'''Step 3: package for moving'''<br />
cd newsystem<br />
sudo tar czf /tmp/debootstrap_$(lsb_release -is | tr "[:upper:]" "[:lower:]")-$(lsb_release -rs)-$(uname -m)''_minbase''.tar.gz .<br />
cd ..<br />
sudo rm -R newsystem<br />
Now you have a package like "debootstrap_ubuntu-10.04-i686.tar.gz" to copy to the OpenVZ host/server.<br />
<br />
'''Unpacking for a new templaye''' (example for 777 container, in the OpenVZ server)<br />
sudo mkdir -p /vz/private/777<br />
cd /vz/private/777<br />
sudo tar xf /tmp/debootstrap_ubuntu-10.04-i686.tar.gz<br />
<br />
'''Next''' steps are the usual for [http://wiki.openvz.org/Category:Templates creating a template].</div>Mosehttps://wiki.openvz.org/index.php?title=Debootstrap_from_foreign_version_or_distribution&diff=9145Debootstrap from foreign version or distribution2010-09-21T13:02:28Z<p>Mose: </p>
<hr />
<div>[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Ubuntu]]<br />
[[Category: Debian]]<br />
<br />
This procedure (for Debian, Ubuntu, and derivatives) is useful when need to create a template, and your host doesn't have that suite's script (in /usr/share/debootstrap/scripts). This situation can be caused because your host and your next template are from different distributions, or because your host is an older version than the next template you want to create (for example, creating an Ubuntu 10.04 template in an Ubuntu 8.04 host).<br />
<br />
To do this, you need a computer to install a clean system or a virtual one with [http://www.qemu.org/ Qemu] or similar.<br />
<br />
'''Step 1: install a system with the distribution & version you want for template'''<br />
<br />
We will call it the "satellite system". You can do it also with another already installed computer with the same distribution & version you want. Also with a Live-CD with sufficient RAM memory available for a subsystem installation.<br />
<br />
'''Step 2: debootstrap''' (in satellite system)<br />
cd /tmp<br />
sudo apt-get install debootstrap<br />
mkdir newsystem<br />
# The parameter ''--variant=minbase'' is optional. You may want it to make a minimal template.<br />
sudo debootstrap --variant=minbase $(lsb_release -cs) newsystem<br />
<br />
'''Step 3: package for moving'''<br />
cd newsystem<br />
sudo tar czf /tmp/debootstrap_$(lsb_release -is | tr "[:upper:]" "[:lower:]")-$(lsb_release -rs)-$(uname -m)''_minbase''.tar.gz .<br />
cd ..<br />
sudo rm -R newsystem<br />
Now you have a package like "debootstrap_ubuntu-10.04-i686.tar.gz" to copy to the OpenVZ host/server.<br />
<br />
'''Unpacking for a new templaye''' (example for 777 container, in the OpenVZ server)<br />
sudo mkdir -p /vz/private/777<br />
cd /vz/private/777<br />
sudo tar xf /tmp/debootstrap_ubuntu-10.04-i686.tar.gz<br />
<br />
'''Next''' steps are the usual for [http://wiki.openvz.org/Category:Templates creating a template].</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=8312Debian template creation2010-03-12T15:50:03Z<p>Mose: </p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>.<br />
<br />
We use VE ID of 777 for this example; surely it can be any other unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing the HN network ==<br />
Append the following lines to /etc/sysctl.conf, adjust to taste and then execute "sysctl -p" for them to take effect.<br />
### OpenVZ settings<br />
<br />
# On Hardware Node we generally need packet<br />
# forwarding enabled and proxy arp disabled<br />
<br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.default.proxy_arp = 0<br />
net.ipv4.ip_forward=1<br />
<br />
# Enables source route verification<br />
net.ipv4.conf.all.rp_filter = 1<br />
<br />
# Enables the magic-sysrq key<br />
kernel.sysrq = 1<br />
<br />
# TCP Explict Congestion Notification<br />
net.ipv4.tcp_ecn = 0<br />
<br />
# we do not want all our interfaces to send redirects<br />
net.ipv4.conf.default.send_redirects = 1<br />
net.ipv4.conf.all.send_redirects = 0<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{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]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian etch main contrib<br />
deb http://security.debian.org etch/updates main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=8309Debian template creation2010-03-12T02:23:25Z<p>Mose: /* Change timezone */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>.<br />
<br />
We use VE ID of 777 for this example; surely it can be any other unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{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]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian etch main contrib<br />
deb http://security.debian.org etch/updates main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
or even better<br />
<source lang="bash"><br />
dpkg-reconfigure tzdata<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=8308Debian template creation2010-03-12T02:22:15Z<p>Mose: /* Customizing the installation */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>.<br />
<br />
We use VE ID of 777 for this example; surely it can be any other unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{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]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian etch main contrib<br />
deb http://security.debian.org etch/updates main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Debian_template_creation&diff=8307Debian template creation2010-03-12T02:19:22Z<p>Mose: /* Customizing the installation */</p>
<hr />
<div>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)<br />
<br />
'''Notes:'''<br />
* 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.<br />
* Anywhere you see <tt>/vz</tt>, you might really need to use <tt>/var/lib/vz</tt> instead, especially on a Debian Etch host.<br />
* 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])<br />
<br />
<br />
== Prerequisites ==<br />
You need to have a working copy of <tt>debootstrap</tt> running on your hardware node.<br />
<br />
For Debian:<br />
sudo apt-get install debootstrap<br />
<br />
For Gentoo:<br />
sudo emerge debootstrap<br />
<br />
For Fedora (at least Fedora 8 have it, not sure about earlier versions):<br />
sudo yum install debootstrap<br />
<br />
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].<br />
<br />
== Bootstrapping Debian ==<br />
<br />
You can install different releases of Debian into a VE's private directory using the debootstrap command.<br />
<br />
The command parameters are:<br />
<br />
debootstrap --arch ARCH NAME DIRECTORY URL<br />
<br />
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>.<br />
<br />
We use VE ID of 777 for this example; surely it can be any other unused ID.<br />
<br />
=== Lenny (current Debian stable) ===<br />
<br />
debootstrap --arch i386 lenny /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Etch (old release) ===<br />
<br />
debootstrap --arch i386 etch /vz/private/777 http://http.us.debian.org/debian/<br />
<br />
=== Sarge (very old release) ===<br />
<br />
debootstrap sarge /vz/private/777 http://archive.debian.org/debian<br />
<br />
== Preparing and starting the VE ==<br />
<br />
=== Setting VE config ===<br />
First, we need a config for the [[VE]]:<br />
sudo vzctl set 777 --applyconfig vps.basic --save<br />
<br />
=== Setting VE OSTEMPLATE ===<br />
Also, we need <tt>OSTEMPLATE</tt> to be set in VE configuration file, for the [[vzctl]] to work properly.<br />
<br />
sudo sh -c 'echo "OSTEMPLATE=debian-4.0" >> /etc/vz/conf/777.conf'<br />
<br />
=== Setting VE IP address ===<br />
For the [[VE]] to be able to download updates from the Internet, we need a valid IP address for it:<br />
sudo vzctl set 777 --ipadd x.x.x.x --save<br />
<br />
{{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]].}}<br />
<br />
=== Setting DNS server for VE ===<br />
For the [[VE]] to be able to download updates from the Internet, we also need to specify a DNS for it:<br />
sudo vzctl set 777 --nameserver x.x.x.x --save<br />
<br />
=== Starting VE ===<br />
Now start the VE:<br />
sudo vzctl start 777<br />
<br />
== Customizing the installation ==<br />
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:<br />
sudo vzctl enter 777<br />
export PATH=/sbin:/usr/sbin:/bin:/usr/bin<br />
<br />
{{Warning|Do not run the commands below on the hardware node, they are only to be run within the VE!}}<br />
<br />
=== Set Debian repositories ===<br />
cat <<EOF > /etc/apt/sources.list<br />
deb http://http.us.debian.org/debian etch main contrib<br />
deb http://security.debian.org etch/updates main contrib<br />
EOF<br />
<br />
=== Get new security updates ===<br />
apt-get update<br />
apt-get upgrade<br />
<br />
=== Install some more packages ===<br />
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:<br />
apt-get install ssh quota less<br />
<br />
=== Set the timezone ===<br />
dpkg-reconfigure tzdata<br />
<br />
=== Set sane permissions for <tt>/root</tt> directory ===<br />
chmod 700 /root<br />
<br />
=== Disable root login ===<br />
This will disable root login by default.<br />
usermod -L root<br />
<br />
=== Disable getty ===<br />
Disable running <tt>getty</tt>s on terminals as a VE does not have any:<br />
sed -i -e '/getty/d' /etc/inittab<br />
<br />
=== Disable <tt>sync()</tt> for syslog ===<br />
Turn off doing <tt>sync()</tt> on every write for <tt>syslog</tt>'s log files, to improve I/O performance:<br />
<pre>sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf</pre><br />
<br />
=== Fix <tt>/etc/mtab</tt> ===<br />
Link <tt>/etc/mtab</tt> to <tt>/proc/mounts</tt>, so <tt>df</tt> and friends will work:<br />
rm -f /etc/mtab<br />
ln -s /proc/mounts /etc/mtab<br />
<br />
=== Remove some unneeded packages ===<br />
If you have any packages you'd like to remove, now's the time for it. Here's an example:<br />
dpkg --purge modutils ppp pppoeconf pppoe pppconfig<br />
<br />
=== Disable services ===<br />
Do not start some services, stick to bare minimum:<br />
update-rc.d -f klogd remove<br />
update-rc.d -f quotarpc remove<br />
update-rc.d -f exim4 remove<br />
update-rc.d -f inetd remove<br />
<br />
=== Fix SSH host keys ===<br />
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.<br />
<br />
<!-- please do not remove <source>...</source> pair of tags below,<br />
otherwise quotes after -N (-N '') are not visible --><br />
<source lang="bash"><br />
rm -f /etc/ssh/ssh_host_*<br />
cat << EOF > /etc/rc2.d/S15ssh_gen_host_keys<br />
#!/bin/bash<br />
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ''<br />
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ''<br />
rm -f \$0<br />
EOF<br />
chmod a+x /etc/rc2.d/S15ssh_gen_host_keys<br />
</source><br />
<br />
<br />
=== Change timezone ===<br />
<br />
You might want to change timezone if you do not live in $UTC. The following example is for Germany<br />
<br />
<source lang="bash"><br />
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime<br />
</source><br />
<br />
=== Clean packages ===<br />
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.<br />
apt-get clean<br />
<br />
Now everything is done. Exit from the template and go back to the hardware node.<br />
exit<br />
<br />
== Preparing for and packing template cache ==<br />
<br />
We don't need an IP for the VE anymore, and we definitely do not need it in template cache, so remove it:<br />
sudo vzctl set 777 --ipdel all --save<br />
<br />
Also, remove DNS server and search domain information from ''/etc/resolv.conf'' file '''in VE''':<br />
sudo nano /vz/private/777/etc/resolv.conf<br />
<br />
Also, remove ''/etc/hostname'' file '''in VE''':<br />
sudo rm -f /vz/private/777/etc/hostname<br />
<br />
Stop the VE:<br />
sudo vzctl stop 777<br />
<br />
Go to the VE directory:<br />
cd /vz/private/777<br />
<br />
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).<br />
sudo tar --numeric-owner -zcf /vz/template/cache/debian-4.0-i386-minimal.tar.gz .<br />
<br />
Look at the resulting tarball to see its size is sane:<br />
# ls -lh /vz/template/cache<br />
-rw-r--r-- 1 root root 51M Apr 10 03:16 debian-4.0-i386-minimal.tar.gz<br />
<br />
== Checking if template cache works ==<br />
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.<br />
sudo vzctl create 123456 --ostemplate debian-4.0-i386-minimal<br />
<br />
Now make sure that it works:<br />
sudo vzctl start 123456<br />
sudo vzctl exec 123456 ps ax<br />
<br />
You should see that a few processes are running.<br />
<br />
== Final cleanup ==<br />
Stop and remove the test VE you just created:<br />
sudo vzctl stop 123456<br />
sudo vzctl destroy 123456<br />
sudo rm /etc/vz/conf/123456.conf.destroyed<br />
<br />
Finally, let's remove the VE we used for OS template cache creation:<br />
sudo vzctl destroy 777<br />
sudo rm /etc/vz/conf/777.conf.destroyed<br />
<br />
[[Category: HOWTO]]<br />
[[Category: Templates]]<br />
[[Category: Debian]]</div>Mosehttps://wiki.openvz.org/index.php?title=Postgresql_and_shared_memory&diff=8211Postgresql and shared memory2010-02-14T04:06:50Z<p>Mose: </p>
<hr />
<div>When running PostgreSQL or Oracle XE (APEX), some nuances of shared memory may arise.<br />
<br />
==== PostgreSQL ====<br />
One of the easiest ways to increase Postgres's performance is to turn up the shared_buffers parameter in the postgresql.conf file. This is basically the amount of shared memory which the postmaster will use for buffering everything: table data, indexes, etc. The default value is really small, and if you have RAM to spare you may want to crank it up to 128MB (16384 shared buffers, for pgsql 8.1 and earlier) or even more. After changing shared_buffers, it might complain that it couldn't allocate the shared memory, even though plenty of memory exists.<br />
<br />
==== Oracle XE ====<br />
A similar situation may occur when installing Oracle XE. The installation appears to succeed, but only the listener is running. No database instance is running. The database directory (/usr/lib/oracle/xe/oradata/XE) is empty. The log file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump/alert_XE.log contains only a couple of lines that indicate success (but there should be many lines of output). Files in /usr/lib/oracle/xe/app/oracle/admin/XE/udump have an odd error "skgm warning: ENOSPC creating segment of size..." and suggest a change to the shared memory configuration, even though the shared memory values are what Oracle recommends. During installation, Oracle will add entries to /etc/sysctl.conf to set shared memory parameters.<br />
<br />
==== Shared Memory ====<br />
There are two things that control shared memory in a container.<br />
<br />
1. The shmpages setting for this container (check [[UBC]]). This dictates how many pages (one page is usually 4K, see [[memory page]] for more details) are available to the container, e.g. shmpages=16384 gives a limit of 64 MB of shared memory.<br />
<br />
2. "/sbin/sysctl kernel.shmmax" This is the container's self-imposed limit in bytes of how much shared memory may be allocated in a single request. You may check the shared memory configuration with "ipcs -l".<br />
<br />
The HN imposes a limit on the container's total shared memory usage through shmpages, and the container itself imposes a limit on the container's total shared memory usage through kernel.shmmax. If the size of shmpages is less than kernel.shmmax, the database will not be able to allocate sufficient memory.<br />
<br />
==== Notes ====<br />
* Shared memory is taken from the container's overall memory allocation. It is not a second memory pool.<br />
<br />
* Other processes may be using shared memory, and shmpages includes things other than IPC shared memory (tmpfs, shmem, etc.). If this is the case for your container, set shmpages higher than the database requires.<br />
<br />
* The sysctl kernel.shmmax value set in the [[HN]]/[[CT0]] applies only to the [[HN]], not to [[container]]s.<br />
<br />
[[Category:FAQ]]<br />
[[Category:Kernel]]<br />
[[Category:Troubleshooting]]</div>Mosehttps://wiki.openvz.org/index.php?title=Oracle_XE_(APEX)_and_shared_memory&diff=8210Oracle XE (APEX) and shared memory2010-02-14T03:14:03Z<p>Mose: Redirected page to Postgresql and shared memory</p>
<hr />
<div>#REDIRECT:[[Postgresql_and_shared_memory]]<br />
<br />
[[Category:FAQ]]<br />
[[Category:Kernel]]<br />
[[Category:Troubleshooting]]</div>Mose