[lxc-users] lxc insttability

[Bostjan Skufca]

Tnx for insight Guido.

But this "bug" only happens on RH-based hosts, or not?

It might be that it is happening on others too and I am not noticing it as
devices detach from bridges and do not interfere with active networking.

If this is common case, then maybe LXC itself should rename stale interface
to ORIGNAME.stale.$RANDOM or something, in order to avoid problems with
fixed interface names.

For me, the question to look into is why devices not not detach from
bridge, not why do they not disappear altogether.

b.


On 19 February 2016 at 20:33, Guido Jäkel <G.Jaekel at dnb.de> wrote:

> Dear Bostjan
>
> The veth will not disappear after shutdown of the container until all
> pending TCP connections through this veth-pair are timed out
> (CLOSE/FIN-WAIT). Sometimes, i even can't delete it on the host. And
> because, i name the host-side of each veth to the name of the container, i
> have to get rid of it to start the Container again. I use
>
>         ip link set dev $DEV name away.$RANDOM
>
> to archive this
>
> Guido
>
>
>
>
> On 19.02.2016 17:08, Bostjan Skufca wrote:
> > Does it delete both interfaces, the one in host's namespace which is
> added
> > to bridge (vethX) and the one in container's namespace (appears as ethX
> in
> > there) too?
> >
> > b.
> >
> >
> > On 19 February 2016 at 11:58, Fajar A. Nugraha <list at fajar.net> wrote:
> >
> >> On Fri, Feb 19, 2016 at 5:41 PM, Bostjan Skufca <bostjan at a2o.si> wrote:
> >>
> >>> I had similar experience using CentOS 7 as host.
> >>>
> >>> I did not investigate it yet, but for some reason veth network
> interfaces
> >>> were not being destroyed when containers stopped, and this could only
> be
> >>> seen with "brctl show" as more interfaces were attached to a bridge
> than
> >>> there were containers running. The effect was that multiple network
> >>> interfaces with the same MAC were attached to the bridge and successful
> >>> connections were, well, sporadic.
> >>>
> >>> On the first inspection it only happened to some containers that had
> >>> explicit mounts from outside (unconfirmed!, just a hunch for now).
> >>>
> >>>
> >>
> >> I use a workaround:
> >>
> >> # ls -la /etc/lxc/script/net-down
> >> -rwxr-xr-x 1 197623 197121 36 Apr 27  2015 /etc/lxc/script/net-down
> >>
> >>
> >> # cat /etc/lxc/script/net-down
> >> #!/bin/bash
> >> /sbin/ip link del "$5"
> >>
> >>
> >> # grep script /var/lib/lxc/rdp/config
> >> lxc.network.script.down = /etc/lxc/script/net-down
> >>
> >>
> >> The correct interface name is passed as argument to script executed
> >> by lxc.network.script.down.
> >>
> >> --
> >> Fajar
> >>
> >>
> >> _______________________________________________
> >> lxc-users mailing list
> >> lxc-users at lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> >>
> >
> >
> >
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160219/07ec9ed6/attachment.html>