lkml.org 
[lkml]   [2008]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectcontainer userspace tools
Hi all,

I saw different emails from people asking for user space tools for the
containers, so I made a library and a set of command line tools.
This component is called "lxc" which stands for "LinuX Container".

The package can be found in the download area of:
http://sourceforge.net/projects/lxc

There is a cvs repository at:
http://lxc.cvs.sourceforge.net/lxc

The API is exported in the "lxc.h" header file.

It is not perfect, but it is very light and I hope that will make the
life easier for the kernel hackers.
It can be used to create virtual private server and to "boot" a minimal
distro like "debian minimal".

It takes into account the control groups and the checkpoint/restart API
... in a very optimistic way :)
It should be used with the kernel coming from the git tree,
git://git.kernel.org/pub/scm/linux/kernel/git/daveh/linux-2.6-lxc.git
But the latest -mm should be ok, some commands will just fail (eg.
checkpoint/restart).

How to use it ?
--------------------

(for checkpointr/restart see the end of the explanation for this very
specific, experimental use case).

A container should be created before with (or without) a configuration file.

The configuration file has the following format (all fields are optional):

# set the hostname for the container
lxc.utsname = myhostname
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.name = eth0
lxc.network.hwaddr = 4a:49:43:49:79:bf
lxc.network.ipv4 = 1.2.3.5/24
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597
lxc.mount = fstab
lxc.rootfs = rootfs
lxc.cgroup.cpuset.cpus = 1
lxc.cgroup.cpu.shares = 512

This is an example, but the configuration file can be much more simple
or complex. In this example the configuration assume the host is
configured with a bridge, the liblxc does not configure anything not
related to the container, so it is up to the user/administrator to setup
a bridge in this case. If the bridge is a problem, different network
configurations exist to have a container to communicate with the outside
world.
The network can be specified with several ip addresses, or either if
there is only one physical network device, it is possible to specify
multiple network devices for the container. To do that just replicate
the network sections as follow:

lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.name = eth0
lxc.network.ipv4 = 192.168.9.100/24
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.name = eth1
lxc.network.ipv4 = 192.168.10.100/24

The more there are informations in the configuration file, the more the
container is isolated. eg. if the network section is removed from the
configuration file, the network won't be virtualized, the same for the
ustname.

Step 1 : create the container named 'foo' with the configuration file
'lxc.conf'

lxc-create -n foo -f lxc.conf

If no configuration file is specified, the container will be created
with default configuration, that is to say, pid namespace, mount
namespace and ipc namespace. The other resources, network, file system,
utsname, won't be virtualized.

Step 2 : launch a command inside

lxc-execute -n foo /bin/bash
or
lxc-start -n foo /bin/bash

The differences between lxc-execute and lxc-start are, lxc-execute
creates an intermediate process for the pid namespace in order to
support daemons and it mounts /proc and /sys.

Step 3 : Stop the container (from outside of the container)

lxc-stop -n foo

Step 4 : Destroy the container

lxc-destroy -n foo

ps: it is not mandatory to destroy the container, you can keep the
configuration and execute/start the command again. That means after a
reboot, the container configuration is still available.

These are the minimal steps to use a container, but there are some other
useful commands:
lxc-freeze / lxc-unfreeze => stop / resume all processes running
inside the container
lxc-monitor => follow the different states of the
container
lxc-wait => wait for a specific state
before exiting (useful for scripting)
lxc-ps => show all non-virtualized pids
of a container
lxc-info => show the state of the container
lxc-cgroup => get/set cgroup info for this
container

Checkpoint/Restart:
--------------------------

The checkpoint / restart is currently *very* experimental, and takes
into account only one task. For this reason the **lxc-start** command
*must* be used.

The easiest way is specifying a container with the minimal isolation
for the minimal CR :)

lxc-create -n ckpt

lxc-start -n ckpt ./myverysimpleprogram

lxc-checkpoint -n ckpt -s > myckptfile

lxc-restart -n ckpt < myckptfile

ps: you have just to create one time the container.

The lxc-checkpoint command will do freeze - checkpoint - unfreeze, if
the '-s' option is set, the container is stopped after the checkpoint.

I hope that will make people to have fun with the containers and the new
kernel features.

Thanks.
-- Daniel


\
 
 \ /
  Last update: 2008-10-10 13:05    [W:0.066 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site