VirtualizeHowto (2002.11.01 07:01:09)

We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

Note: This Howto is in its early stage of development. At the moment it is mainly just a copy of a message I posted to the mailing list about the gotchas I found in virtualizing an old Red Hat 6.2 box to run as a vserver on a Red Hat 9 machine. (Chuck)

Virtualizing for Fun & Profit

Virtualize: Convert a standard Linux server (i.e. one of them on a physical machine) to run as a vserver inside another physical server (called the host server).

Why? Because running as a vserver gives you: simplified Backup, very neat Failover (rsync the vserver to another box, then when the main servers just run "vserver <vserver> start"), & easy Upgrade possibilities (create another vserver with a newer distro, migrate files/users across at your leisure).

How? That's what this document is for! There are three steps:

1. Patch the host server kernel.
2. Install the vserver tools on the host server.
3. rsync your old server to /vservers/oldserver/ on the host server.
4. Configure /etc/vservers/oldserver.conf.
5. Enter the vserver and modify the configuration so it'll work as a vserver.

Information on patching the kernel and installing the vserver tools should be somewhere else on this site. Rsyncing isn't too difficult (but maybe I'll add details later). So I'll start at number 4, configuring the vserver.

VServer Configuration (/etc/vservers/<vserver>.conf)

• Add CAP_SYS_RESOURCE to S_CAPS if you want to run BIND in the vserver.

• Change ULIMIT="-H -u 1000" to ULIMIT="-HS -u 1000".

Inside the VServer

(Run "vserver oldvserver enter" to get into the vserver. Don't make these changes on the host server!)

• Edit /etc/rc.d/init.d/syslog, commenting out the lines that start and stop klogd (only the host server should get the kernel log messages).

• Turn off useless (in a vserver) services: network, rawdevices, random, ntp, etc. (To do this run, for example, "chkconfig off network")

• Remove any unnecessary kill scripts hanging around in /etc/rc.d/rc3.d/. Kill scripts start with a K. These were executing when I stopped my vserver, trying to do things like disable the network interfaces. Not sure why "chkconfig off <service>" didn't remove these.

• Remove /etc/rc.d/rc.sysinit. This kept trying to do things like add swap space when I started the vserver.

• Edit /etc/rc.d/rc.local and remove any unnecessary lines (e.g. for me, running hdparm).

• Edit /etc/resolv.conf and change the nameserver setting to point to the vserver's IP instead of 127.0.0.1. Not sure why this was needed, but name resolution was very slow until I changed this. Maybe I shouldn't have played with the loopback address...

• Fix the permissions on a few directories that were set to 0 (i.e. chmod 0 dir), because vserver uses chmod 0 to stop people breaking chroot. It took me a while to work out why even as root I couldn't read anything in these directories. A chmod u+rx fixed that.

• I also had problems at the start where inet & httpd refused to bind to their ports, saying someone else had those open. I think I must have still had a test vserver running with an overlapping IP. Killing all processes in the other vservers fixed this...

• "find / -user 25 | xargs chown named; find / -group 25 | xargs chgrp named;" -- Needed this because rsync had decided to change the owner of named's files to UID 25 (which is named's UID on the host server), from UID 11 (which was named's UID on the old server).

• "chgrp utmp /var/log/wtmp" -- as with named the rsync had changed the UID. (A quick check of man rsync tells me I should have done the rsync with the -p option - would have avoided this problem and the previous one.)

• Totally unrelated to vserver issue: sysstat decided to stop working because I'd moved from a single CPU system to an SMP system. Fix by "rm /var/log/sa/*".

Finally, once everything is working well:

• "arping -S NEW.IP -c 5 BROADCAST.ADDRESS" to tell everyone the new MAC address of the server.

So all in all there aren't many general settings to be changed after you rsync the server into a vserver. I found the resolver issues and the named permissions problem took the most time to fix. Give it a go - there's not much to lose!