container userspace tools

[Ian jonhson]

> The container will be more or less isolated depending of what you specify in
> the configuration file.
>
yes

> Without any configuration file, you will have pid, ipc and mount points
> isolated. If you specify the utsname, it will be isolated and if you specify
> the network you will have a new network stack allowing to run for example a
> new sshd server.
>

hmm.... then, how to configure the container to get the isolation of
pid, ipc and
mount points? I have looked through the whole configuration example in README
and fond the following settings(which are not tried in my test because
I don't understand
them very well)

 * lxc.mount: is it to mount a file (or volume) so that all the
processes in this container can
    access the content in file?
 * lxc.utsname: I don't know what exact functionlity of this setting is.
 * lxc.network.xxx: are there other options expect
"link","hwaddr","ipv4" and "ipv6"?
 * lxc.rootfs:for application writing data in it?

I am now looking into the codes and find some information about what the
container can do maximally. It seems all the configuration settings are
binding with a container and all the schedules are based on container unit.
Configuration settings only can be setup before container creation and
can not be changed in container lifecycle, right?


> In the other side, the cgroup are tied with the container, so you can
> freeze/unfreeze all processes belonging to the container, change the
> priority or assign an amount of physical memory to be used by the container.
>

In my brain, the cgroup is mainly used in multiple CPUs. In traditional single
CPU machine, can the container separate or determine how much CPU cycle
are used by its processes now? Also, administrator has to configure cgroup
before it takes action. I have no idea whether both of cgroup and container are
totally integrate with each other, or both of them have to be handle
in some cases.


> Allowing to assign quota per container is a good idea, but I don't think it
> is supported by the kernel right now. Perhaps there is a trick to do that
> but I don't know it :)
>
I would like to do this part of job. Also, I need to control several groups of
processes (belonged to same user) in the same time, isolating them,
enforced them with given resource quota, and freeze/unfreeze some of
them.

BTW, as for checkpointing of container, is it easy to checkpoint/restart
given group of processes in above example?

> The rootfs option allows you to specify the root file system to be used by
> the container, so if you specify it, your container will be chrooted inside.
> This feature is at a very early stage and will be improved in the future,
> allowing to example to specify a iso image of a file system tree and make
> use of it.
>

Good. what kinds of rootfs are supported now?  I fond there are a debian file
in sourceforge, is it a rootfs image?


> There are two contributions which are good examples on how to setup a
> container, I added them to:
>
> http://sourceforge.net/projects/lxc/
>
> The first one is a chroot of a sshd server and the second one is a
> minimalist debian showing a full distro booting.
>

In sourceforge, there are

*  	sshd.tar.gz
*  	debian.tar.gz
*       utsname (actually, utstest.c)

I wonder what is the utstest.c?


Thanks again,

Ian