Re: veth won't be configured in libvirt managed LXC container
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
Re: veth won't be configured in libvirt managed LXC container
On Sat, 2014-10-18 at 16:00 -0400, Gene Czarcinski wrote: 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? This may be related to a problem in libvirt-sandbox (Secure Containers): https://www.redhat.com/archives/libvir-list/2014-September/msg00540.html Does that mean lxc (or libvirt or whatever) is supposed to configure the interface before spawning the container? In that case it would indeed make sense for NM to assume the connection. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: veth won't be configured in libvirt managed LXC container
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. 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 create a connection for the veth device NM won't touch it anyway, would it? -- 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
Re: veth won't be configured in libvirt managed LXC container
On 10/19/2014 09:53 AM, Lubomir Rintel wrote: On Sat, 2014-10-18 at 16:00 -0400, Gene Czarcinski wrote: 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? This may be related to a problem in libvirt-sandbox (Secure Containers): https://www.redhat.com/archives/libvir-list/2014-September/msg00540.html Does that mean lxc (or libvirt or whatever) is supposed to configure the interface before spawning the container? In that case it would indeed make sense for NM to assume the connection. My only experience is with Secure Containers created by virt-sandbox-service of the libvirt-sandbox package. Without my patches, you can successfully create a virtual NIC with either static or dhcp addresses. With dhcp, dhclient needs to be started. Without the patches, dhcp does not work. I do not know if this problem applies generally to containers or not. Although not a secure container, the following does work: virt-sandbox -c lxc:/// -N dhcp,source=default /bin/sh I has some problem with chrony but, when you get in, ip addr will show eth0 with an address Now, through all of this, NetworkManager is going nuts trying to get dhclient to work with vnetN but it never succeeds. Could someone who understands what NetworkManager should be doing and why explain. It is certainly not clear to me that NetworkManager should be doing anything! Gene -- ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: veth won't be configured in libvirt managed LXC container
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? This may be related to a problem in libvirt-sandbox (Secure Containers): https://www.redhat.com/archives/libvir-list/2014-September/msg00540.html However, I do find it very annoying that NetworkManager insists on playing with the vnet interfaces. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: veth won't be configured in libvirt managed LXC container
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... -- Dan 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
