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

[Michael Tokarev]

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.

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.

/mjt