[lxc-devel] lxc final thesis

Daniel Lezcano daniel.lezcano at free.fr
Wed Mar 2 21:10:30 UTC 2011


On 02/28/2011 11:20 AM, Farcasi Ana-Maria wrote:
> Hi,
>
> Indeed, we were refering to the network bandwidth limitation. Sorry for the
> confusion.
>
> We have already done some tests with this limitation using tc and cgroups
> and we have reached the conclusion that the classification is done
> correctly, but the limitation of the bandwidth is not done at all. Here we
> have attached our results [1].
>
> We also found this kind of experiments done by some other persons too and
> they reached the same conclusion. An example is that from the link [2].
>
> We were thinking to take a look in the kernel too, to see if we can do
> something to make the limitation work correctly. Is it a wrong path?

My knowledge on network bandwidth limitations is poor, so I am not sure.
Are you sure we need a cgroup for bandwidth limitations ? Shouldn't 
apply to a specific network device ? so we can assign a bandwidth 
limitation to the network device of the container ?

> Also, we are open to work on other features for lxc, too if there is
> something to be done.

Great ! Welcome !

There is a lot of stuff todo, here is a quick list:

kernel:

  * cgroup disk/file quotas

lxc userspace core:

  * routes configuration
  * more network configuration (tun/tap)

lxc scripts:

  * a comprehensive tool to create containers (eg. a configuration wizard)

The idea with the lxc tools is there are some low level, highly 
configurable, binaries and on top of that there is a bigger script using 
these binaries and providing a most common configuration, very secure 
and isolated. Something similar to how is invoked git.

For example:

lxc-start, lxc-create, lxc-destroy and the upper tool equivalent is "lxc 
start", "lxc create", "lxc destroy".


> [1] http://swarm.cs.pub.ro/~irinap/lxc_test
> [2]
> https://lists.linux-foundation.org/pipermail/containers/2009-June/018595.html




More information about the lxc-devel mailing list