NAME lxc - linux containers QUICK START You are in a hurry, and you don’t want to read this man page. Ok, without warranty, here are the commands to launch a shell inside a container with a predefined configuration template, it may work. lxc-execute -n foo -f /etc/lxc/lxc-macvlan.conf /bin/bash OVERVIEW The container technology is actively being pushed into the mainstream linux kernel. It provides the resource management through the control groups aka process containers and resource isolation through the namespaces. The linux containers, lxc, aims to use these new functionnalities to pro- vide an userspace container object which provides full resource isolation and resource control for an applications or a system. The first objective of this project is to make the life easier for the ker- nel developers involved in the containers project and especially to con- tinue working on the Checkpoint/Restart new features. The lxc is small enough to easily manage a container with simple command lines and complete enough to be used for other purposes. REQUIREMENTS The lxc relies on a set of functionnalies provided by the kernel which needs to be active. Depending of the missing functionnalities the lxc will work with a restricted number of functionnalities or will simply fails. The following list gives the kernel features to be enabled in the kernel to have the full features container: * General * Control Group support -> namespace cgroup subsystem -> cpuset support -> Group CPU scheduler -> control group freeze subsystem -> Basis for grouping tasks (Control Groups) -> Simple CPU accounting -> Resource counters -> Memory resource controllers for Control Groups -> Namespace support -> UTS namespace -> IPC namespace -> User namespace -> Pid namespace * Network support -> Networking options -> Network namespace support For the moment the easiest way to have all the features in the kernel is to use the git tree at: : git://git.kernel.org/pub/scm/linux/kernel/git/daveh/linux-2.6-lxc.git But the kernel version >= 2.6.27 shipped with the distros, may work with lxc, this one will have less functionnalities but enough to be interesting. The planned kernel version which lxc should be fully functionnaly is 2.6.29. Before using the lxc, your system should be configured with the file capa- bilities, otherwise you will need to run the lxc commands as root. The con- trol group should be mounted anywhere, eg: mount -t cgroup cgroup /cgroup FUNCTIONAL SPECIFICATION A container is an object where the configuration is persistent. The appli- cation will be launched inside this container and it will use the configu- ration which was previously created. How to run an application in a container ? Before running an application, you should know what are the resource you want to isolate. The default configuration is isolation of the pids, the sysv ipc and the mount points. If you want to run a simple shell inside a container, a basic configuration is needed, especially if you want to share the rootfs. If you want to run an application like sshd, you should provide a new network stack and a new hostname. If you want to avoid conflicts with some files eg. /var/run/httpd.pid, you should remount /var/run with an empty directory. If you want to avoid the conflicts in all the cases, you can specify a rootfs for the container. The rootfs can be a directory tree, previously bind mounted with the initial rootfs, so you can still use your distro but with your own /etc and /home Here is an example of directory tree for sshd: [root@lxc sshd]$ tree -d rootfs rootfs |-- bin |-- dev | |-- pts | ‘-- shm | ‘-- network |-- etc | ‘-- ssh |-- lib |-- proc |-- root |-- sbin |-- sys |-- usr ‘-- var |-- empty | ‘-- sshd |-- lib | ‘-- empty | ‘-- sshd ‘-- run ‘-- sshd and the mount points file associated with it: [root@lxc sshd]$ cat fstab /lib /home/root/sshd/rootfs/lib none ro,bind 0 0 /bin /home/root/sshd/rootfs/bin none ro,bind 0 0 /usr /home/root/sshd/rootfs/usr none ro,bind 0 0 /sbin /home/root/sshd/rootfs/sbin none ro,bind 0 0 How to run a system in a container ? Running a system inside a container is paradoxically easier than running an application. Why ? Because you don’t have to care about the resources to be isolated, everything need to be isolated except /dev which needs to be remounted in the container rootfs, the other resources are specified as being isolated but without configuration because the container will set them up. eg. the ipv4 address will be setup by the system container init scripts. Here is an example of the mount points file: [root@lxc debian]$ cat fstab /dev /home/root/debian/rootfs/dev none bind 0 0 /dev/pts /home/root/debian/rootfs/dev/pts none bind 0 0 A good idea to have the console is to mount bind this one to our tty, so we see the output of the system container booting and we can log to it /proc/self/fd/0 /home/root/debian/rootfs/dev/console none bind 0 0 These examples are avaible in the contrib package located at: https://sourceforge.net/projects/lxc/ CONTAINER LIFE CYCLE When the container is created, it contains the configuration information. When a process is launched, the container will be starting and running. When the last process running inside the container exits, the container is stopped. In case of failure when the container is initialized, it will pass through the aborting state. --------- | STOPPED |<--------------- --------- | | | start | | | V | ---------- | | STARTING |--error- | ---------- | | | | | V V | --------- ---------- | | RUNNING | | ABORTING | | --------- ---------- | | | | no process | | | | | V | | ---------- | | | STOPPING |<------- | ---------- | | | --------------------- CONFIGURATION The container is configured through a configuration file, the format of the configuration file is described in lxc.conf(5) CREATING / DESTROYING THE CONTAINERS The container is created via the lxc-create command. It takes a container name as parameter and an optional configuration file. The name is used by the different commands to refer to this container. The lxc-destroy command will destroy the container object. lxc-create -n foo lxc-destroy -n foo STARTING / STOPPING A CONTAINER When the container has been created, it is ready to run an application / system. When the application has to be destroyed the container can be stopped, that will kill all the processes of the container. Running an application inside a container is not exactly the same thing as running a system. For this reason, there is two commands to run an applica- tion into a container: lxc-execute -n foo [-f config] /bin/bash lxc-start -n foo [/bin/bash] lxc-execute command will run the specified command into a container but it will mount /proc and autocreate/autodestroy the container if it does not exist. It will furthermore create an intermediate process, lxc-init, which is in charge to launch the specified command, that allows to support dae- mons in the container. In other words, in the container lxc-init has the pid 1 and the first process of the application has the pid 2. lxc-start command will run the specified command into the container doing nothing else than using the configuration specified by lxc-create. The pid of the first process is 1. If no command is specified lxc-start will run /sbin/init. To summarize, lxc-execute is for running an application and lxc-start is for running a system. If the application is no longer responding, inaccessible and is not able to finish by itself, a wild lxc-stop command will kill all the processes in the container without pity. lxc-stop -n foo FREEZE / UNFREEZE A CONTAINER Sometime, it is useful to stop all the processes belonging to a container, eg. for job scheduling. The commands: lxc-freeze -n foo will put all the processes in an ininteruptible state and lxc-unfreeze -n foo will resume all the tasks. This feature is enabled if the cgroup freezer is enabled in the kernel. GETTING INFORMATION ABOUT THE CONTAINER When there are a lot of containers, it is hard to follow what has been cre- ated or destroyed, what is running or what are the pids running into a spe- cific container. For this reason, the following commands give this informa- tion: lxc-ls lxc-ps -n foo lxc-info -n foo lxc-ls list the containers of the system. The command is a script built on top of ls, so it accepts the options of the ls commands, eg: lxc-ls -1 will display the containers list in one column or: lxc-ls -l will display the containers list and their permissions. lxc-ps will display the pids for a specific container. Like lxc-ls, lxc-ps is built on top of ps and accepts the same options, eg: lxc-ps -n foo --forest will display the process hierarchy for the container ’foo’. lxc-info gives informations for a specific container, at present only the state of the container is displayed. Here is an example on how the combination of these commands allow to list all the containers and retrieve their state. for i in $(lxc-ls -1); do lxc-info -n $i done And displaying all the pids of all the containers: for i in $(lxc-ls -1); do lxc-info -n $i done And displaying all the pids of all the containers: for i in $(lxc-ls -1); do lxc-ps -n $i --forest done MONITORING THE CONTAINERS It is sometime useful to track the states of a container, for example to monitor it or just to wait for a specific state in a script. lxc-monitor command will monitor one or several containers. The parameter of this command accept a regular expression for example: lxc-monitor -n "foo|bar" will monitor the states of containers named ’foo’ and ’bar’, and: lxc-monitor -n ".*" will monitor all the containers. SETTING THE CONTROL GROUP FOR A CONTAINER The container is tied with the control groups. A control group can be setup when the container is running to change or to retrieve its value. lxc-cgroup command is used to set or get a control group subsystem which is associated with a container. The subsystem name is handle by the user, the command won’t do any syntax checking on name, if the name does not exists, the command will fail. lxc-cgroup -n foo cpuset.cpus will display the content of this subsystem. lxc-cgroup -n foo cpus.share 512 will set the subsystem to the specified value. BUGS The lxc is still in development, so the command syntax and the API can change. The version 1.0.0 will be the frozen version. SEE ALSO lxc-create(1), lxc-destroy(1), lxc-start(1), lxc-execute(1), lxc-stop(1), lxc-monitor(1), lxc-wait(1), lxc-cgroup(1), lxc-ls(1), lxc-ps(1), lxc- info(1), lxc-freeze(1), lxc-unfreeze(1), lxc.conf(5), AUTHOR Daniel Lezcano