[Lxc-users] Is there any document on networking?

[Rami Rosen]

Hi,
There is a  very detailed lecture I gave with many examples about
namespaces, and network namespaces in particular, and also about cgroups.
They are both used in Linux containers.
It is a pdf  of 121 pages!

See:

www.haifux.org/lectures/299/netLec7.pdf

I hope it can help.

Regards
Rami Rosen

http://ramirose.wix.com/ramirosen
 בתאריך 12 בנוב 2013 15:32, "Magicloud Magiclouds" <
magicloud.magiclouds at gmail.com> כתב:

> OK. Thank you. I have read the article on netns. But got no idea how a
> process knows what netns it should use. I read some source of LXC to figure
> it out....
>
>
> On Tue, Nov 12, 2013 at 7:10 PM, Fajar A. Nugraha <list at fajar.net> wrote:
>
>> On Tue, Nov 12, 2013 at 4:37 PM, Magicloud Magiclouds <
>> magicloud.magiclouds at gmail.com> wrote:
>>
>>> I kind of understand a bit. So the guest processes are assigned to the
>>> netns created by LXC, right?
>>>
>>>
>> Correct.
>>
>> If you ONLY want to test netns,
>> http://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/is a good howto. You need to create&setup the interface manually, but in
>> terms of networking it's pretty much what lxc does.
>>
>> --
>> Fajar
>>
>>
>>>
>>> On Tue, Nov 12, 2013 at 2:42 PM, Fajar A. Nugraha <list at fajar.net>wrote:
>>>
>>>> On Tue, Nov 12, 2013 at 1:22 PM, Magicloud Magiclouds <
>>>> magicloud.magiclouds at gmail.com> wrote:
>>>>
>>>>> Thank you for the reply. I may be not clear in the original question.
>>>>>
>>>>> For example, in KVM, the system setup a virtual network device pair in
>>>>> host, and added on end to bridge. So when an program is using the other
>>>>> end, its communication will be bridged to actual hardware. And KVM exposes
>>>>> a virtual network device to the guest and links it to "the other end". And
>>>>> in guest, it is just a normal network device.
>>>>>
>>>>> But in LXC, first of all, it does not vitualize hardware. The guest is
>>>>> just a child process of LXC. Then, how does it make the guest using "the
>>>>> other end"? The guest is just using general socket APIs.
>>>>>
>>>>>
>>>>
>>>> If you use the default LXC setup, then most likely you're already using
>>>> veth for networking. So you already have a pair of veth interface, one on
>>>> the host, and the other on the guest. The host and the guest can see
>>>> different network device since they're using different network namespace.
>>>>
>>>> In my setup, I use something like this on lxc config ("ffmpeg" is the
>>>> name of the container):
>>>>
>>>> lxc.network.type=veth
>>>> lxc.network.link=br0
>>>> lxc.network.flags=up
>>>> lxc.network.hwaddr= 00:16:3E:45:B9:78
>>>> lxc.network.veth.pair=v-ffmpeg-0
>>>> lxc.utsname = ffmpeg
>>>>
>>>> What it does:
>>>> - it uses veth for network
>>>> - the veth interface on the host side would always be named
>>>> "v-ffmpeg-0", connected to the bridge "br0" (created separately using
>>>> networking config in the hosts's /etc/network/interfaces)
>>>> - the veth interface on the container/guest side is named "eth0", with
>>>> MAC address 00:16:3E:45:B9:78
>>>>
>>>> --
>>>> Fajar
>>>>
>>>
>>>
>>>
>>> --
>>> 竹密岂妨流水过
>>> 山高哪阻野云飞
>>>
>>> And for G+, please use magiclouds#gmail.com.
>>>
>>
>>
>
>
> --
> 竹密岂妨流水过
> 山高哪阻野云飞
>
> And for G+, please use magiclouds#gmail.com.
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Lxc-users mailing list
> Lxc-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20131121/c63cfe0d/attachment.html>