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

[Daniel Lezcano]

Michael Tokarev wrote:
> Daniel Lezcano wrote:
>> 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.
> 
> The "manual" is not "type".
> 
> What we have now is a mix of device type (veth, macvlan, phys) and a
> way it's connected (namely, veth always assumes a bridge).  This mix
> should be solved.
> 
> But I think my current way (the patch in $subject), while still not
> 100% logical, does both things - keeping the config compatible with
> previous versions and allowing veth to be used freely by letting NOT
> specifying "link" parameter.
> 
> Speaking of veth - is there any other "link" for such a device except
> of a bridge?  I can't think of one.  And this makes whole thing to fly,
> I think.

The code in lxc assumes it is a bridge which covers 99% of the use 
cases, but that could be bonding for example or vlan.

> Note the above lxc.network.bridge thing -- it is again valid only for
> veth.
> 
>> 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.
> 
> Yeah, but we still need the type.  "Connection" might be manual (but it
> is again only valid for veth), but type stands.
> 
> So I think the original way is valid.