[lxc-devel] lxc final thesis

[Farcasi Ana-Maria]

Hello,

Ok. Thank you very much for your advice! We will try to implement these two
features: provisioning and limitation.

Ana & Irina.

On Sat, Mar 19, 2011 at 11:52 PM, Daniel Lezcano <daniel.lezcano at free.fr>wrote:

> On 03/18/2011 06:40 PM, Farcasi Ana-Maria wrote:
>
>> Hello,
>>
>> As mentioned in our previous email, we were having issues getting
>> bandwidth
>> limitation working on cgroup ( with net_cls ) and tc. We've been running
>> various tests and scenarios but found no way to enable proper limitation.
>> Throughout our testing we've created a virtual machine running a 2.6.35
>> kernel where the limitation was indeed working.
>>
>> We've browsed recent commits in the Linux-2.6 kernel source code and
>> discovered that ever since version 2.6.35 (actually ever since this
>> commit[1] was integrated), there is a change in getting the packet classid
>> -
>> the classid is stored and read as a member of a struct sock. As this is
>> also
>> used by LXC, it means that ever since 2.6.35, bandwidth limitation using
>> tc
>> is working for cgroups.
>>
>> In order to prove this, we've compiled the latest 2.6.34 and 2.6.35
>> kernels
>> (2.6.34.8 and 2.6.35.11). We've used tc, cgroup (net_cls) and iperf to
>> test
>> this.
>>
>> On the latter version ( 2.6.35.11 ) the limitation is working accordingly,
>> while on the former ( 2.6.34.8 ) the limitation is not working at all. We
>> believe the above mentioned commit[1] is responsible for solving this
>> issue
>> and post-2.6.35 kernels should have no problems using cgroup-based
>> bandwidth
>> limitation (for example, within LXC).
>>
>> We were thinking whether it would be a good idea to integrate an option
>> for
>> bandwidth limitation into an LXC container configuration file (such as
>> lxc.network.bwlimit). This would allow a rapid setup of an LXC container
>> and
>> network limitation. This could, of course, be set up using tc (it would
>> take
>> a bit more effort, though). What do you think?
>>
>
>
> Hi Irina and Ana,
>
> Thanks for investigating this, it is very useful.
>
> Adding the setup to lxc is a good idea and I will be happy to merge
> upstream your modifications to take into account the bandwidth limitations.
>
> As far as I remember the bandwidth limitations is for download and upload
> no ? If it is the case, I would recommend to use the options:
>
> lxc.network.bandwidth.download = value
> lxc.network.bandwidth.upload = value
>
> I thought another feature would be interesting, the network provisioning. I
> don't if it is supported by the kernel (I don't think so) but if we can
> assign for example 1GB of download/upload to the container and when it is
> reached the network become stuck until we add more provisioning, that could
> be very useful. What do you think ?
>
> Thanks
>  -- Daniel
>
>  <javascript:void(0);>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20110321/d074c8d9/attachment.html>