Re: veth won't be configured in libvirt managed LXC container

[Dan Williams <dcbw redhat com>]

On Sun, 2014-10-19 at 16:03 +0200, Lubomir Rintel wrote:
> On Fri, 2014-10-17 at 09:28 -0400, Dan Winship wrote:
> > There's a bunch of discussion about this in
> > https://bugzilla.gnome.org/show_bug.cgi?id=731014. The short answer is
> > "it's complicated", because veths get used for a bunch of different
> > things in different situations...
>
> I'm not sure I understand the outcome there.

I'm not sure there was a concrete outcome yet.

There are really two cases here:

1) inside the container/VM - treat like normal Ethernet, including
"default DHCP" if that's enabled in the NM configuration

2) on the host - treat as default-unmanaged and assume connections that
are configured by Docker/LXC/libvirt/etc without touching the
interfaces.

We used to always do #1, but now we always do #2 because of Docker.  It
would be great to do both at the appropriate time...  does that all make
sense?

> Not assuming assuming the connection on a device that is in fact not
> configured does not imply doing DHCP on that device. If the user won't

The question is, "what does configured mean?"

NM considers an interface with only an IPv6LL address to be configured,
because that's a valid network configuration.  Unfortunately the kernel
assigns an IPv6LL address automatically on IFF_UP, whether the
administrator intends that or not.  So NM doesn't know whether the
administrator *intends* the IPv6LL-only configuration, or whether they
did nothing.  We don't have a solution for this yet.

(Tangent: technically any interface that is IFF_UP is "configured"
because something/someone explicitly set that.  This would also handle
L2-only configurations, which is something we want to do.
Unfortunately, you have to set the device IFF_UP to get carrier events,
and then the kernel assigns IPv6LL address too :(

The ideal situation for all this would be (a) treat any IFF_UP interface
as "configured" and assume it's connection even if L2-only, (b) enable
carrier detection without IFF_UP, (c) don't always set IFF_UP on
devices.

We investigated kernel changes to disambiguate carrier detection from
IFF_UP, but that was a non-starter as it would require changes to every
single driver, or complicated core changes to work around having to
change every driver...)

> create a connection for the veth device NM won't touch it anyway, would
> it?

It shouldn't touch veth automatically because they are "default
unmanaged", which means you have to explicitly activated/deactivate
them.

Dan

> > -- Dan
>
> Lubo
>
> > On 10/16/2014 07:08 AM, Lubomir Rintel wrote:
> > > Hi,
> > >
> > > currently it is impossible to get useful network configuration for LXC 
> > > containers on boot. (At least if they're managed via libvirt; I have no
> > > idea if anything is different with native LXC tooling). They're supposed
> > > to obtain their configuration via DHCP, but instead connection is assumed.
> > > Firstly because there's an IPv6 local link address that (I think) gets
> > > assigned when libvirt ups the interface and secondly because it's a 
> > > software link.
> > >
> > > Why do we assume connection on all software links? Virtual ethernet devices
> > > are supposed to behave much like ordinary ethernet devices; they have 
> > > carrier detection, etc.
> > >
> > > I'm following up with the patches that resolve the problem for me, but 
> > > I'm not quite sure about the special case for veth. 
> > >
> > > Thoughts?
> > >
> > > Thank you,
> > > Lubo
> > >
> > > _______________________________________________
> > > networkmanager-list mailing list
> > > networkmanager-list gnome org
> > > https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list