Difference between revisions of "Building Guest Systems"
From Linux-VServer
(0.416666666666667) |
|||
(17 intermediate revisions by 12 users not shown) | |||
Line 1: | Line 1: | ||
− | + | == Building a guest == | |
+ | |||
+ | There are three parts to the <code>vserver ... build</code> command. Each part is separated by <code>--</code>. 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 <code>-m <method></code> 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 <code>vserver - build --help</code> to see them all. | ||
+ | |||
+ | === Building guests using the debootstrap build method === | ||
+ | '''''(applies to Debian, Ubuntu,...)''''' | ||
+ | * Build a Debian lenny guest using the ftp.de.debian.org mirror. | ||
+ | vserver vserver1 build \ | ||
+ | -m debootstrap --[[context]] 42 \ | ||
+ | --hostname vserver1.mydomain.com \ | ||
+ | --interface eth0:192.168.1.10/24 \ | ||
+ | -- -d lenny -m http://ftp.de.debian.org/debian | ||
+ | lenny can be replaced by e.g. etch for Debian etch, edgy for Ubuntu edgy, or sid for Debian sid. Anything your debootstrap version can handle will be fine. | ||
+ | |||
+ | If you want to build a 32-bit guest on a 64-bit host, append <code>-- --arch i386</code> to the above command line. The same applies to other additional debootstrap options: place them after a second <code>--</code>. Likewise, in case your host architecture does not match one available in Debian by default, add your architecture in the same way. E.g. you might need to add <code>-- --arch amd64</code> to create a 64-bit Debian guest on a Gentoo host. | ||
+ | |||
+ | Please note that <code>vserver...pkgmgmt</code> has has no use on Debian guests: package management is internalized by default and cannot be externalized. To externalize package management on Debian vserver guests, you have to create the guest using the <code>newvserver</code> command from the <code>vserver-debiantools</code> Debian package (see the <code>--pkgcache</code> option). Note that newvserver is considered obsolete and only suited for those who want to foot themselves in shoot. | ||
+ | |||
+ | |||
+ | === Building guests using the yum build method === | ||
+ | '''''(applies to Fedora, Centos, RHEL,...)''''' | ||
+ | * Make sure that your host system already has yum installed, preferably one that has been patched to work better with chroots. | ||
+ | |||
+ | * Build a CentOS 5-based guest using a minimal set of packages. | ||
+ | vserver vserver2 build -m yum --[[context]] 42 \ | ||
+ | --hostname vserver2.mydomain.com \ | ||
+ | --interface eth0:192.168.1.11/24 -- -d centos5 | ||
+ | centos5 can be replaced by e.g. f8 for Fedora 8, or fc6 for Fedora 6. | ||
+ | |||
+ | If you want to build a 32-bit guest on a 64-bit, prepend <code>linux32</code> 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 | ||
+ | vserver vserver2 exec bash -c "rm -f /var/lib/rpm/__db*; rpm --rebuilddb" | ||
+ | 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. | ||
+ | vserver vserver3 build -m template \ | ||
+ | --[[context]] 42 --hostname vserver3.mydomain.com \ | ||
+ | --interface eth0:192.168.1.12/24 \ | ||
+ | --initstyle gentoo -- -d gentoo \ | ||
+ | -t /vservers/.templates/stage4-i686-20070905.tar.bz2 | ||
+ | |||
+ | '''OR''' | ||
+ | |||
+ | * Build a guest using multiple templates, one named stage4-i686-20070905.tar.bz2 and one named httpd.tar.bz2. | ||
+ | vserver vserver3 build -m template \ | ||
+ | --[[context]] 42 --hostname vserver3.mydomain.com \ | ||
+ | --interface eth0:192.168.1.12/24 \ | ||
+ | --initstyle gentoo -- -d gentoo \ | ||
+ | -t /vservers/.templates/stage4-i686-20070905.tar.bz2 \ | ||
+ | -t /vservers/.templates/httpd.tar.bz2 | ||
+ | |||
+ | === 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. | ||
+ | |||
+ | * Build a guest by rsync'ing from vserver3 on host1. | ||
+ | RSYNC_RSH=ssh | ||
+ | vserver vserver4 build -m rsync --[[context]] 42 \ | ||
+ | --hostname vserver4.mydomain.com \ | ||
+ | --interface eth0:192.168.1.13/24 \ | ||
+ | -- --source root@host1:/vservers/vserver3 | ||
+ | |||
+ | '''OR''' | ||
+ | |||
+ | * Build a guest by rsync'ing from vserver1 on the same host. | ||
+ | vserver vserver4 build -m rsync --[[context]] 42 --hostname vserver4.mydomain.com --interface eth0:192.168.1.13/24 -- --source vserver1 | ||
+ | |||
+ | === 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. | ||
+ | |||
+ | * Build a guest by using vserver4 as a reference. | ||
+ | vserver vserver5 build -m clone --hostname vserver5.mydomain.com --interface eth0:192.168.1.14/24 -- --source /vservers/vserver4 | ||
== Post-build customization == | == Post-build customization == | ||
Line 25: | Line 110: | ||
* [[Installing Ubuntu on Debian]] | * [[Installing Ubuntu on Debian]] | ||
* [[Installing 32-bit Fedora on 64-bit Debian]] | * [[Installing 32-bit Fedora on 64-bit Debian]] | ||
+ | |||
+ | [[Category:Documentation| ]] | ||
+ | [[Category:OS guest under linux-vserver| ]] |
Latest revision as of 21:56, 21 October 2011
Contents |
[edit] 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.
[edit] Building guests using the debootstrap build method
(applies to Debian, Ubuntu,...)
- Build a Debian lenny guest using the ftp.de.debian.org mirror.
vserver vserver1 build \ -m debootstrap --context 42 \ --hostname vserver1.mydomain.com \ --interface eth0:192.168.1.10/24 \ -- -d lenny -m http://ftp.de.debian.org/debian
lenny can be replaced by e.g. etch for Debian etch, edgy for Ubuntu edgy, or sid for Debian sid. Anything your debootstrap version can handle will be fine.
If you want to build a 32-bit guest on a 64-bit host, append -- --arch i386
to the above command line. The same applies to other additional debootstrap options: place them after a second --
. Likewise, in case your host architecture does not match one available in Debian by default, add your architecture in the same way. E.g. you might need to add -- --arch amd64
to create a 64-bit Debian guest on a Gentoo host.
Please note that vserver...pkgmgmt
has has no use on Debian guests: package management is internalized by default and cannot be externalized. To externalize package management on Debian vserver guests, you have to create the guest using the newvserver
command from the vserver-debiantools
Debian package (see the --pkgcache
option). Note that newvserver is considered obsolete and only suited for those who want to foot themselves in shoot.
[edit] Building guests using the yum build method
(applies to Fedora, Centos, RHEL,...)
- Make sure that your host system already has yum installed, preferably one that has been patched to work better with chroots.
- Build a CentOS 5-based guest using a minimal set of packages.
vserver vserver2 build -m yum --context 42 \ --hostname vserver2.mydomain.com \ --interface eth0:192.168.1.11/24 -- -d centos5
centos5 can be replaced by e.g. f8 for Fedora 8, or fc6 for Fedora 6.
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
vserver vserver2 exec bash -c "rm -f /var/lib/rpm/__db*; rpm --rebuilddb"
This is required if every rpm operation, for example rpm -qa, complains about a database version mismatch.
[edit] 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.
vserver vserver3 build -m template \ --context 42 --hostname vserver3.mydomain.com \ --interface eth0:192.168.1.12/24 \ --initstyle gentoo -- -d gentoo \ -t /vservers/.templates/stage4-i686-20070905.tar.bz2
OR
- Build a guest using multiple templates, one named stage4-i686-20070905.tar.bz2 and one named httpd.tar.bz2.
vserver vserver3 build -m template \ --context 42 --hostname vserver3.mydomain.com \ --interface eth0:192.168.1.12/24 \ --initstyle gentoo -- -d gentoo \ -t /vservers/.templates/stage4-i686-20070905.tar.bz2 \ -t /vservers/.templates/httpd.tar.bz2
[edit] 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.
- Build a guest by rsync'ing from vserver3 on host1.
RSYNC_RSH=ssh vserver vserver4 build -m rsync --context 42 \ --hostname vserver4.mydomain.com \ --interface eth0:192.168.1.13/24 \ -- --source root@host1:/vservers/vserver3
OR
- Build a guest by rsync'ing from vserver1 on the same host.
vserver vserver4 build -m rsync --context 42 --hostname vserver4.mydomain.com --interface eth0:192.168.1.13/24 -- --source vserver1
[edit] 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.
- Build a guest by using vserver4 as a reference.
vserver vserver5 build -m clone --hostname vserver5.mydomain.com --interface eth0:192.168.1.14/24 -- --source /vservers/vserver4
[edit] Post-build customization
[edit] Verifying guest functionality
- Once the guest is built, it's time to start it.
vserver vserverX start
- At this point, you can use both
vserver vserverX enter
and
vserver vserverX exec ...
to do things inside the guest.
- To stop it, simply use
vserver vserverX stop
[edit] How to remove a screwed up vserver
- To to remove a screwed up vserver
vserver vserverX delete