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: dhclient: avoiding hostname disclosure via DHCP request
I've backported those patches to F20 for you, can you try: https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-46.git20131003.fc20 and let me know if it fixes the issue? Thank you for building that package - unfortunately it doesn't work for me (hostname still included in requests). After upgrading to NetworkManager-0.9.9.0-46.git20131003.fc20.x86_64 I added DHCP_HOSTNAME=wont-be-used #(tested with and without that line) DHCP_SEND_HOSTNAME=no to /etc/sysconfig/network-scripts/ifcfg-SSID but wireshark still shows my hostname in DHCP requests. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
