<div>Hello David,</div><div><br></div><div>You may try the patch below (kernel v2.6.35) and see if that helps. It basically does what you asked for: during namespace cleanup, move back the virtual interfaces to their original namespaces. I did some tests with veth pairs and nested netns's and everything worked fine.</div>
<div><br></div><div>I think this should be the default behaviour, I would like if someone could review/fix this patch and push it upstream.</div><div><br></div><div>Have a good day,</div><div>Renato.</div><br><div class="gmail_quote">
2011/2/26 Daniel Lezcano <span dir="ltr"><<a href="mailto:daniel.lezcano@free.fr">daniel.lezcano@free.fr</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 02/26/2011 05:59 PM, Ward, David - 0663 - MITLL wrote:<br>
> (Apologies for the cross-post, but Thunderbird messed up the formatting<br>
> when I sent this originally, and then I realized I sent it to the wrong<br>
> list.)<br>
><br>
> A patch was applied to the kernel in November 2008 that deletes virtual<br>
> network interfaces when network namespaces are cleaned up<br>
> (d0c082cea6dfb9b674b4f6e1e84025662dbd24e8). A discussion about this<br>
> patch took place on this list<br>
> (<a href="https://lists.linux-foundation.org/pipermail/containers/2008-October/013460.html" target="_blank">https://lists.linux-foundation.org/pipermail/containers/2008-October/013460.html</a>),<br>
> where Daniel Lezcano wrote:<br>
><br>
>  > After discussing with Benjamin, this patch means an user can no longer<br>
>  > manage a pool of virtual devices because they will be automatically<br>
>  > destroyed when the namespace exits. I don't think it is a big concern,<br>
>  > but just in case I am asking :)<br>
><br>
> I currently have two use cases where this behavior is not desirable:<br>
><br>
> 1. I use a veth pair device to connect two containers together (as<br>
> opposed to connecting a container to the host). To do this, I<br>
> create the veth pair device manually in the host with iproute2<br>
> ("ip link add type veth"). Then when I start each container, it<br>
> pulls in one of the interfaces of the veth pair device with<br>
> "lxc.network.type = phys". When I stop one of the containers, its<br>
> interface to the veth pair device is deleted instead of moved back<br>
> to the host, so I can not just start the stopped container again<br>
> and re-establish the same link.<br>
<br>
</div>Maybe you can rely on the lxc configuration to do that.<br>
<br>
Assuming you create the two container always in the same order.<br>
<br>
The first one:<br>
<br>
lxc.network.type=veth<br>
lxc.network.veth.pair=vethX<br>
<br>
The second one<br>
<br>
lxc.network.type=phys<br>
lxc.network.link=vethX<br>
<br>
The drawback is you have to stop / start both of them.<br>
<br>
<br>
Otherwise, why don't you use the macvlan configuration ?<br>
<br>
For both containers:<br>
<br>
lxc.network.type=macvlan<br>
lxc.network.macvlan.mode=bridge<br>
lxc.network.link=dummy0<br>
<div class="im"><br>
<br>
> 2. I start a process in the host that creates a TUN/TAP interface,<br>
> such as a VPN client. I pull the TUN/TAP interface into the<br>
> container with "lxc.network.type = phys". When the container<br>
> exits, the TUN/TAP interface is deleted because it is a virtual<br>
> interface, while the VPN client process continues to run in the<br>
> host. Again I can not just start the container again with the<br>
> same connection; I have to restart the VPN client.<br>
><br>
> It makes sense that virtual network interfaces that get created inside a<br>
> container should be deleted when the container exits. However, I feel<br>
> that network interfaces from the host that get assigned to the container<br>
> should be returned to the host when the container exits, whether they<br>
> are physical or virtual.<br>
<br>
</div>Wouldn't make sense to add a configuration option for lxc to create such<br>
device and handle the vpn client ?<br>
<br>
There is the lxc.network.script.up option where you can launch your vpn<br>
client. So adding the tun/tap interface as a network option, lxc will<br>
create it for you and when it is up, the up script is invoked where the<br>
vpn client is launched.<br>
<br>
The lxc.network.script.down does not exist yet, but it is quite easy to<br>
add the option.<br>
<br>
What do you think ?<br>
<div class="im"><br>
> Can the kernel distinguish between network interfaces that were created<br>
> inside the namespace, and network interfaces that were moved there?<br>
<br>
</div>IMHO that will add more complexity to the network namespace, especially<br>
to handle the nested namespaces. Furthermore that will impact the<br>
current design. I am not really in favor of that as that was initial<br>
behavior and there were limitations.<br>
  <javascript:void(0);><br>
_______________________________________________<br>
Containers mailing list<br>
<a href="mailto:Containers@lists.linux-foundation.org">Containers@lists.linux-foundation.org</a><br>
<a href="https://lists.linux-foundation.org/mailman/listinfo/containers" target="_blank">https://lists.linux-foundation.org/mailman/listinfo/containers</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Renato Westphal<br>