[lxc-devel] network devices

[Andrian Nord]

On Sat, Nov 14, 2009 at 09:15:29PM +0300, Michael Tokarev wrote:
> In particular, it is not clear at all if macvlan works with bridge or
> veth should be used instead.  So far I learned that macvlan does _not_
> work with linux bridge (neither when attached to the bridge nor to the
> physical port), but veth works.  I'm not sure if it's intentional or
> not.

MAC-VLAN is actually some kind of alias. It has several design
restrictions. You should use it when you want to provide
access to physical device inside of container. phys will not work with
sysfs compiled in, as for now.

> So the first question actuall is - is there any documentation about
> veth and especially macvlan and their usage cases - where to use one
> and where another.  (veth come from openvz if memory serves me right,
> and there is quite some documentation about it there).

Yes, there is - google =). I haven't seen any better source. Also
KConfig from kernel has some minimal information.

Don't know about the source, but here veth serves same function as
openvz's venet has - it's most common way of networking =)

> To sum it up, I think that allowing empty lxc.network.link for veth
> type is a good idea.  It's a one-liner, but it does not work still.

Yes, it might be useful.

> 1) allowing empty network.link for network.type=veth (if it's empty,
>    don't join it to bridge)
> 
> 2) allowing to specify a host-side name of veth link.  This is the
>   problem place for me, I don't know a good name for it.  Maybe the
>   whole thing should be named a bit differently to avoid possible
>   confusion of host vs container parts.  For example:
>     lxc.network.container.name = eth0
>     lxc.network.host.link = br0
>     lxc.network.host.name = eth-container0
>   Using something like 'hostname' is even more confusing :)

Maybe?
lxc.network.bridge = br0
lxc.network.pair = eth1234

Also it could be useful to specify some primitive routing operations
inside of config =)