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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
