Building a guest

There are three parts to the vserver ... build command. Each part is separated by --. The first part are generic vserver options, such as hostname, available IP-addresses, and context id. The second part is specific to the chosen build method (by -m <method> in the first part). The third part is completely optional and only implemented for a few build methods. These are options passed directly to whatever application is used to build guest.

There are a lot of options not covered here (yet). Use vserver - build --help to see them all.

If you want to build a 32-bit guest on a 64-bit, prepend linux32 to this and subsequent yum commands.

If you want to manage the packages inside the guest, you will have to install some package management program(s) as well as internalize the RPM database. This can be achieved by

vyum vserver2 -- install yum
vserver vserver2 pkgmgmt internalize

Internal package management means that commands such as rpm, yum and rpmbuild can be used from inside the guest, as opposed to requiring the host administrator to run vrpm or vyum. If you use rpmbuild, you'll need internal package management, or use --nodeps (but that's strongly discouraged).

Depending on your host's/guest's distribution, you may also need to do

This is required if every rpm operation, for example rpm -qa, complains about a database version mismatch.

Building guests using the template build method

(applies to Gentoo,...)

A template is a file containing a complete guest filesystem. This can be a tar(1)ball, a cpio(1)-archive, or a dump(8). It can be compressed using either gzip or bzip2. Multiple templates can be used, to do e.g. guest-specific modifications.

Build a guest using a single template named stage4-i686-20070905.tar.bz2 located in /vservers/.templates.

Building guests using the rsync build method

The rsync build method can be used to move a guest from one system to another. It is preferable for most guest distributions if the source guest is stopped when you create a one based on it, but it's not strictly required.

Building guests using the clone build method

The clone build method copies the filesystem from one guest to another, much like the rsync build method, but the thing that separates it is that it knows about unified/hashified files. This means that it only creates new links for such files, and copies the rest, which can lead to significantly speedier builds.