[lxc-devel] network devices

[Daniel Lezcano]

Michael Tokarev wrote:
> Hello again.
> The more I dig into lxc utils, the more questions I have... ;)
> Now it's about network.
>
> First of all, there's almost no documentation about various network
> drivers involved, especially macvlan.  It is mentioned in alot of
> places, but nothing about what it is and hwo to use it.
>
> 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.
>   

> 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).
>   
macvlan are like ip aliased but at the eth level.
pros:
    * macvlan are fast, easy to setup
cons:
    * can not communicate with another container on the same host
    * switch the physical eth to the promiscuous mode

veth are pair devices, like a pipe.
pros:
    * support all kind of traffic
    * inter container communication
cons:
     * the physical interface offloading capability is lost in the container

> Back to lxc.
>
> When specifying lxc.network.type=veth, it is assumed that the 'link'
> parameter is also specified and it points to a bridge.  Here I've
> numerous (kvm) guests which uses routed network instead of bridging --
> that is, a per-guest tun device (some guests have more than one),
> and a set of per-device routes.  But lxc network setup code actually
> requires bridge, it fails if link is not specified or if it is not
> a bridge.  But veth works just fine without bridge in routed mode, --
> I verified it by commenting out the bridge setup calls in veth
> handler, and configuring the host node's side of it.
>   
Yes this another kind of configuration, as well as doing some nat.
> 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.
>
> Because there's no way to specify which name is used for the host
> part of veth pair.  lxc-start chooses a random name for the link.
> So it is impossible to tell which interface belongs to which container,
> impossible to configure firewall rules and the like, and impossible
> to configure the host side of veth link further.
>
> So it looks like 3 things are needed here:
>
> 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 :)
>   
> 3) actually implementing runnung a script to configure container's
>   namespace - to configure the host part of the veth link.
>