The instructions below assume that you use at least Owl-current as of 2009/11/23 or newer (you're likely to use our 3.0 release made in December 2010). You may use the live CD system (after having set a root password, having configured networking with setup, and having “exited” the single-user mode shell to boot into multi-user), or you may install Owl on hard drive(s) first.
If you're going to experiment with OpenVZ while CD-booted, you may need to expand the size of /ram, which defaults to half your machine's RAM. On a 1 GB RAM system (which is about the minimum for this), you may do:
mount /ram -oremount,size=950M
Additionally, there was a known issue with OpenVZ disk quotas while running CD-booted. This issue has been addressed with the 2010/01/28 ISO snapshots (and newer). If you're using one of the older Owl ISOs generated on 2009/11/23, then the easiest workaround is to disable the quotas by editing /etc/vz/vz.conf to set DISK_QUOTA=no (the default is yes). On an installed system, this is not needed (the quotas are working fine and are very useful indeed).
Please start by downloading a pre-created OpenVZ template of your Linux distribution of choice. OpenVZ team's official pre-created templates of (almost) minimal installs of many Linux distributions are available at http://download.openvz.org/template/precreated/. Additional templates are available in the contrib/ sub-directory. It is expected that once a container is instantiated with one of these, additional packages will be downloaded/installed using the target distribution's proper tools, as necessary for the container's specific intended use.
To illustrate further steps, we'll use Fedora 11 (fedora-11-x86.tar.gz), although this choice is somewhat arbitrary. You may use lftpget to download this right to the Owl system (lftp, including the lftpget wrapper script, is included in Owl).
Update (2009/12/01): We have started to generate and make available pre-created templates of the Owl userland (i686 and x86_64) such that you can easily create containers with Owl, whether on an Owl system or not. These templates are available under /pub/Owl/current/vztemplate on our FTP mirrors, and they're to be used with the /etc/vz/dists/owl.conf distribution-specific settings file (available on both Owl and non-Owl systems - this file had been submitted upstream earlier, so it is part of the vanilla vzctl package by now). Our template filenames are chosen such that owl.conf will be used along with these templates by default. 1) Even though setting up a container with Owl on an Owl system is now easy, the example below uses Fedora 11 as stated above. We may update it to illustrate Owl-on-Owl as well at a later time.
Update (2010, 2011): With our latest ISOs, it is also possible to generate a new template of the Owl userland while CD-booted (such that you don't have to download a template). To do this, issue the command ln -s /usr/src/linux kernel-work; mkdir -p /vz/vztmp/vztree; make vztemplate 2) as root while in the /usr/src/world directory. The resulting template will be placed right in /vz/template/cache (just where you're going to need it for the next steps) and its filename will be owl-current-20YYMMDD.tar.gz. Please note that the temporary tree under /vz/vztmp/vztree will continue to occupy memory unless you remove it manually (which may be a good thing to do before you proceed further as you're going to need the memory for instantiating and running a container).
On the Owl system (installed or CD-booted), place the template under /vz/template/cache. (When CD-booted, /vz is located on tmpfs - that is, in RAM.)
owl!root:~# ls -l /vz/template/cache/ total 200284 -rw------- 2 root root 204884614 Oct 1 21:03 fedora-11-x86.tar.gz
Create the container using vzctl create …. It is recommended that you don't use container IDs below 100, which are reserved for system use. We start with ID 101 here. In the command below, substitute an actual IP address in place of a.b.c.d. If you want to be able to access the container from the outside of your Owl system (as well as access the outside, such as the Internet, from the container), the IP address should be routed to your machine (typically a free IP address in your Ethernet segment). The hostname is not as important.
owl!root:~# vzctl create 101 --ostemplate fedora-11-x86 --ipadd a.b.c.d --hostname fed11.test.openwall.net Creating container private area (fedora-11-x86) Warning: configuration file for distribution fedora-11-x86 not found default used Performing postcreate actions Container private area was created
OK, the choice of Fedora was not entirely arbitrary - it happened to match the default configuration file well. This is the DEF_OSTEMPLATE setting in /etc/vz/vz.conf.
Additional options may need to be passed to vzctl create … above, or to vzctl set … –save later on, such as to set the container (not) to automatically start up when your system boots up - that option is –onboot yes (the current default) or –onboot no. But we're just experimenting, so we don't bother with that yet.
With OpenVZ, the “host system” routes traffic to/from its containers (although this happens within the same instance of the Linux kernel). Thus, in order for the containers to be reachable from the outside (and vice versa), you need to enable IPv4 packet forwarding. You may do it temporarily with:
owl!root:~# sysctl -w net.ipv4.ip_forward=1 net.ipv4.ip_forward = 1
For a more permanent setup (one you would actually use on a server), edit the net.ipv4.ip_forward = 0 line in /etc/sysctl.conf (change the 0 to 1), then issue sysctl -p (to have the new setting apply to the already-booted system as well).
Just before booting up a container, its networking settings are adjusted (via distribution-specific OpenVZ scripts). In order to have the proper nameserver(s) configured in the container's /etc/resolv.conf, they need to be specified with:
owl!root:~# vzctl set 101 --nameserver a.b.c.x --nameserver a.b.c.y --save
The command to start up the container is:
owl!root:~# vzctl start 101 Warning: configuration file for distribution fedora-11-x86 not found default used Starting container ... Container is mounted Adding IP address(es): a.b.c.d Setting CPU units: 1000 Configure meminfo: 65536 Set hostname: fed11.test.openwall.net Container start in progress...
However, this assumes that the vz service is already started (the virtual network interface venet0 already configured), which may or may not be the case. The 2009/11/23 snapshots of Owl-current start the vz service automatically, but future versions will likely skip its startup when there are no containers on system bootup. If needed, we may start the vz service explicitly:
owl!root:~# service vz start Starting OpenVZ: ..done Bringing up interface venet0: ..done Configuring interface venet0: ..done Starting CT 101: ..done
Please note how this also started our container (due to the default of ONBOOT=“yes”, which got into /etc/vz/conf/101.conf). If it did not, we would issue vzctl start 101 after this point.
The running container may be “seen” with vzlist:
owl!root:~# vzlist
CTID NPROC STATUS IP_ADDR HOSTNAME
101 15 running a.b.c.d fed11.test.openwall.net
It is possible to enter the container from the “host system”:
owl!root:~# vzctl enter 101 entered into CT 101 [root@fed11 /]# cat /etc/redhat-release Fedora release 11 (Leonidas)
You may also set a password for the “guest system”:
owl!root:~# vzctl enter 101 entered into CT 101 [root@fed11 /]# passwd Changing password for user root. New password: Retype new password: passwd: all authentication tokens updated successfully. [root@fed11 /]# ssh-keygen -lf /etc/ssh/ssh_host_rsa_key 2048 6f:55:9a:ef:7b:97:f6:96:26:05:8d:7e:0a:05:31:ea /etc/ssh/ssh_host_rsa_key.pub (RSA) [root@fed11 /]# exit
…and then access the Fedora system over SSH (this specific template has the SSH service enabled by default):
another-owl!user$ ssh root@a.b.c.d The authenticity of host 'a.b.c.d (a.b.c.d)' can't be established. RSA key fingerprint is 6f:55:9a:ef:7b:97:f6:96:26:05:8d:7e:0a:05:31:ea. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'a.b.c.d' (RSA) to the list of known hosts. root@a.b.c.d's password: [root@fed11 ~]#
(You have verified the fingerprint prior to entering “yes”, haven't you?)
The Fedora template has the httpd service (web server) started up by default. Let's suppose that we want to access this web server from the Fedora system itself. For this, we may want to add the ELinks package, which is not part of the template. As long as we have configured networking properly so far and the proper external servers are available, we may install the package with yum (which is part of the Fedora template):
[root@fed11 /]# yum install elinks Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package elinks.i586 0:0.12-0.13.pre3.fc11 set to be updated --> Processing Dependency: libnss_compat_ossl.so.0 for package: elinks-0.12-0.13.pre3.fc11.i586 --> Running transaction check ---> Package nss_compat_ossl.i586 0:0.9.5-3.fc11 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: elinks i586 0.12-0.13.pre3.fc11 fedora 1.0 M Installing for dependencies: nss_compat_ossl i586 0.9.5-3.fc11 fedora 37 k Transaction Summary ================================================================================ Install 2 Package(s) Upgrade 0 Package(s) Total download size: 1.0 M Is this ok [y/N]: y Downloading Packages: (1/2): elinks-0.12-0.13.pre3.fc11.i586.rpm | 1.0 MB 00:01 (2/2): nss_compat_ossl-0.9.5-3.fc11.i586.rpm | 37 kB 00:00 -------------------------------------------------------------------------------- Total 529 kB/s | 1.0 MB 00:01 warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2 fedora/gpgkey | 1.6 kB 00:00 Importing GPG key 0xD22E77F2 "Fedora (11) <fedora@fedoraproject.org>" from /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-i386 Is this ok [y/N]: y Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing : nss_compat_ossl-0.9.5-3.fc11.i586 1/2 Installing : elinks-0.12-0.13.pre3.fc11.i586 2/2 Installed: elinks.i586 0:0.12-0.13.pre3.fc11 Dependency Installed: nss_compat_ossl.i586 0:0.9.5-3.fc11 Complete! [root@fed11 /]#
Create a user account and run ELinks:
[root@fed11 /]# useradd -m user [root@fed11 /]# su - user [user@fed11 ~]$ elinks http://localhost
This mostly works fine (displaying the “Fedora Test Page”), except that if you're running this from an Owl system's console, the line drawing characters will be displayed incorrectly. This is because Fedora's ELinks defaults to UTF-8, whereas Owl's console does not. Press ESC for the menu, then choose “Setup” → “Terminal options” and uncheck “UTF-8 I/O”. Then go to “Setup” → “Character set” and choose “ISO 8859-1” (instead of Fedora's default of “Unicode UTF-8”). This results in correct display. This is not exactly an Owl or OpenVZ topic, but it illustrates the minor compatibility issues one may run into and solve, although the same issue could also be seen when accessing any remote Fedora system from any terminal that does not use UTF-8.
Stopping the container is simple:
owl!root:~# vzctl stop 101 Stopping container ... Container was stopped Container is unmounted owl!root:~# vzlist Container(s) not found
Depending on your intentions, you may do some or all of the following.
If you no longer need it, you may opt to stop the vz service, which will shut down the venet0 interface:
owl!root:~# service vz stop Bringing down interface venet0: ..done Stopping OpenVZ: ..done
If you no longer need it, now may be the time to disable IPv4 packet forwarding:
owl!root:~# sysctl -w net.ipv4.ip_forward=0 net.ipv4.ip_forward = 0
(or undo the change to /etc/sysctl.conf and run sysctl -p).
This removes the container's files (the instance of Fedora we installed, ELinks we downloaded, etc.), as well as renames (disables) the container's configuration file under /etc/vz/conf:
owl!root:~# vzctl destroy 101 Destroying container private area: /vz/private/101 Container private area was destroyed