[lxc-devel] [PATCH 3/3] allow lxc.network.pair to specify host-side name for veth interface

Daniel Lezcano daniel.lezcano at free.fr
Wed Nov 18 21:48:24 UTC 2009


Michael Tokarev wrote:
> Michael Tokarev wrote:
>   
>> Currently we allocate veth device with random name on host side,
>> so that things like firewall rules or accounting does not work
>> at all.  Fix this by recognizing yet anothe keyword to specify
>> the host-side device name: lxc.network.pair, and use it instead
>> of random name if specified.
>>     
>
> Now when I think about it... maybe it should be done the other way
> around.  For macvlan, "link" parameter makes sense but this newly
> introduced "pair" is not.  But for veth, this "pair" _is_ link
> actually.  Ie, name of veth1 should be lxc.network.link, and no
> other things like bridge should be specified.  Instead, if bridge
> is needed AND it should be done using config file still, I'd go
> for lxc.network.bridge parameter instead.
>
>
> In sum:
>
>   lxc.network.name = the name on the container side as before
>   lxc.network.link is type-dependent:
>     macvlan: device name to build macvlan on
>     veth: the host side of the pair
>     phy: the host device to pass to container
>       (how about renaming it??)
>     empty: not applicable
>
>   lxc.network.bridge - if specified, add it to the bridge.
>     Probably only valid for veth again, but it can be done
>     unconditionally in the common code and fail with system
>     errno.
>
> To me, the above looks more logical.  But this breaks
> current setup for sure.
>
> Comments?
>   

A new lxc.network.type=manual can be added. With this configuration 
option, lxc will only move the network device to the container and set 
it up. It will be up to the user to create the network device before and 
do the external network configuration setup.
eg. create the pair veth device with the name they want, attach one side 
to the bridge or setup routing or nat rules, etc ...

That fits for macvlan and veth and give the ability to the user to 
implement its own configuration for the outside of the container.




More information about the lxc-devel mailing list