OpenVZ On Debian Etch For Webservers

Want to support HowtoForge? Become a subscriber!
 
Submitted by cies (Contact Author) (Forums) on Tue, 2006-12-19 21:14. :: Debian | OpenVZ | Virtualization

OpenVZ On Debian Etch For Webservers

Introduction

Virtualization is nice! A good practice for servers, since it makes things more secure, scalable, replacable, and replicable. All this at the cost of little added complexity.

This guide is written during an install of a Supermicro machine with 2 dual-core opterons (64-bit), 2 identical disks (for RAID) and a load of memory. Why OpenVZ and not XEN or the recent KVM kernel module? Well, XEN is not very stable for 64-bit architectures (yet), and it comes with quite a bit of overhead (every VM runs its own kernel) due to its complexity. KVM is very simple but restricts you to run a kernel as one process, so the VM cannot benefit from multi core systems.

With OpenVZ only one kernel is run for the host environment _and_ all the VMs, this makes the setup lean and a good candidate for webservers.

Install the hosting system

First install Etch (make sure to set up RAID with the installer).

You might want to rid yourself of some cluttering directories and links in your root (and, as the rest of the guide, as root):

cd /
rm cdrom
unlink vmlinuz.old
unlink vmlinuz
rmdir selinux/
rmdir initrd
unlink initrd.img.old
rmdir opt
rmdir srv/

Now we want to compile a custom OpenVZ enabled kernel, we kind-of followed this guide on the OpenVZ site. A short overview of what we did:

apt-get update
apt-get install linux-source-2.6.18 kernel-patch-openvz vzctl vzquota # this command might need you to acknoledge
cd /usr/src
tar xjvf linux-source-2.6.18.tar.bz2
cd linux-source-2.6.18
cp /boot/config-2.6.18-3-amd64 .config
aptitude install kernel-package # you need it in the next line
make-kpkg --append_to_version=-1-openvz --added_patches=openvz --revision=1 kernel_image
cd ..
dpkg -i linux-image-2.6.18-1-openvz_1_amd64.deb
update-initramfs -c -k 2.6.18-1-openvz
update-grub

Then (after you might have modified the /boot/grub/menu.lst a bit to default to the right kernel) you can reboot.

After the reboot using the OpenVZ enbabled kernel check if all works:

ifconfig # should list your interfaces and an additional "venet" inteface
cat /proc/vz/* # should show somethings (not very important yet what it shows)
cat /proc/cpuinfo # se that your CPUs are up
cat /proc/mdstat # RAIDs working
lsmod # should show some modules starting with the letters "vz"

Make Virtual Private Servers (VPSs)

No we setup, start a VPS from the default minimal template (you can find it in /var/lib/vz/template/cache):

vzctl create 101 --ostemplate debian-3.1-amd64-minimal --config vps.basic
vzctl set 101 --onboot yes --save
vzctl set 101 --hostname test101.mytest.org --save
vzctl set 101 --ipadd 10.0.0.101 --save
vzctl set 101 --numothersock 120 --save
vzctl set 101 --nameserver 10.0.0.2 --save
vzctl set 101 --privvmpages 500000:750000 --save # give it some memory CHECKME
vzctl start 101
vzctl exec 101 passwd

Then you can connect with the VPS by

ssh 10.0.0.101

, and note the colorful prompt...

This template is a Sarge (3.1) template, and I want it to be Etch (4.0), so when logged in to the VPS as root do:

nano /etc/apt/sources.list # edit it to match the sources.list on you host (Etch) install
aptitude update
aptitude dist-upgrade

Now try out your new VPS, and make it workable, install the packages you like to have around since this systems will later serve as basis for further VPSes.

Next we creating a template from the just customized VPS, this is an easy thing:

vzctl stop 101 # stop it
rm -f /var/lib/vz/private/101/etc/ssh/ssh_host_* # remove the keys (new ones will be generated on first boot)
cd /var/lib/vz/private/101/
tar czf /var/lib/vz/template/cache/debian-etch-20061218-amd64.tar.gz .

As Borat would say: "Nice! I like!"

No we can setup and run some additional VPSs, as before but now slightly modified:

vzctl create 102 --ostemplate debian-etch-20061218-amd64 --config vps.basic
vzctl set 102 --onboot yes --save
vzctl set 102 --hostname test102.mytest.org --save
vzctl set 102 --ipadd 10.0.0.102 --save
vzctl set 102 --numothersock 120 --save
vzctl set 102 --nameserver 10.0.0.2 --save
vzctl set 102 --privvmpages 500000:750000 --save # give it some memory CHECKME
vzctl start 102
vzctl exec 102 passwd

and (yes, I see there are not too many interesting changes)...

vzctl create 103 --ostemplate debian-etch-20061218-amd64 --config vps.basic
vzctl set 103 --onboot yes --save
vzctl set 103 --hostname test103.mytest.org --save
vzctl set 103 --ipadd 10.0.0.103 --save
vzctl set 103 --numothersock 120 --save
vzctl set 103 --nameserver 10.0.0.2 --save
vzctl set 103 --privvmpages 500000:750000 --save # give it some memory CHECKME
vzctl start 103
vzctl exec 103 passwd

and start the first VPS (vzctl start 101) since we took it offline for using it as the basis of our template, remember?

now we have 3 VPSs running. Test it with vzlist, output:

      VEID      NPROC STATUS  IP_ADDR         HOSTNAME
       101          5 running 10.0.0.101      test101.mytest.org
       102          5 running 10.0.0.102      test102.mytest.org
       103          5 running 10.0.0.103      test103.mytest.org

VPSs need some memory, be default they are given way too little, so please set the vmguarpages, oomguarpages, privvmpages, etc, etc, etc, in you VPS confiv files (/etc/vz/conf/*.conf) to some sane values -- a page equals 4Kb. The errors that occure because your restricted your VPS too much can be read in by executing:

vzctl exec 101 cat /proc/user_beancounters

The last column of the UBC (user_beancounter) should only contain zeros, if ohterwise try raising some barriers and limits. Consult the OpenVZ documentation for more information on the individual options.

Now we can continue setting up our apaches, postfixes, etceteras on the VPSs... Good luck!

Ohh and below my /etc/vz/conf/101.conf file, it stinks, I just raised some values bluntly because we had error in the user_beancounter.

cat /etc/vz/conf/101.conf

#  Copyright (C) 2000-2006 SWsoft. All rights reserved.
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#
VERSION="2"
ONBOOT="yes"
# UBC parameters (in form of barrier:limit)
# Primary parameters
AVNUMPROC="40:40"
NUMPROC="255:255"
NUMTCPSOCK="80:80"
NUMOTHERSOCK="255:255"
VMGUARPAGES="500000:9223372036854775807"
# Secondary parameters
KMEMSIZE="33554432:36909875"
TCPSNDBUF="319488:524288"
TCPRCVBUF="524288:524288"
OTHERSOCKBUF="439296:439296"
DGRAMRCVBUF="132096:132096"
OOMGUARPAGES="500000:9223372036854775807"
# Auxiliary parameters
LOCKEDPAGES="32:32"
SHMPAGES="8192:8192"
PRIVVMPAGES="500000:750000"
NUMFILE="10240:10240"
NUMFLOCK="100:110"
NUMPTY="16:16"
NUMSIGINFO="256:256"
DCACHESIZE="1048576:1097728"
PHYSPAGES="0:9223372036854775807"
NUMIPTENT="128:128"
# Disk quota parameters (in form of softlimit:hardlimit)
DISKSPACE="1048576:1153434"
DISKINODES="200000:220000"
QUOTATIME="0"
# CPU fair sheduler parameter
CPUUNITS="1000"
OFFLINE_MANAGEMENT="yes"
VE_ROOT="/var/lib/vz/root/$VEID"
VE_PRIVATE="/var/lib/vz/private/$VEID"
OSTEMPLATE="debian-3.1-amd64-minimal"
ORIGIN_SAMPLE="vps.basic"
HOSTNAME="101.mytest.org"
IP_ADDRESS="10.0.0.101"
NAMESERVER="10.0.0.2"

Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by kir (registered user) on Mon, 2007-01-01 19:34.

Let me warn you that your configuration is wrong. You should always check the changes you made to a VE configuration using the vzcfgvalidate tool. In your case, it gives (at least) the following:

Error: othersockbuf.lim-othersockbuf.bar should be > 652800 (currently, 0)
Warning: tcprcvbuf.lim-tcprcvbuf.bar should be > 204800 (currently, 0)

The problem  is quite severe: since you set the barrier and the limit for othersockbuf to the same value, there is no "safety gap" between bar and lim, thus the system will act severe if there will be othersockbuf shortage. Same problem with tcprcvbuf.

For more info about these specific parameters, see http://wiki.openvz.org/UBC_secondary_parameters

For info of how to configure your UBC (and other resource management) settings, see http://wiki.openvz.org/Resource_shortage 

Overall UBC info is at http://wiki.openvz.org/UBC. 

Finally, it makes no sense to publish a config with IP_ADDRESS and NAMESERVER variables.

Submitted by simas (registered user) on Fri, 2007-03-02 14:12.

In this how-to it is not mentioned, that virtual machines will not have access to internet. To allow VM acces internet, you must enable NAT on hosting server:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to external_ip 

Submitted by simas (registered user) on Fri, 2007-03-02 08:34.
I want to warn you, that there is no any prepared image in /var/lib/vz/template/cache in Debian Etch by default, you should get it manually from http://openvz.org/download/template/cache