[systemd-devel] systemd-nspawn network-interface
Hello Regaining of the network-interface, as is stated in the manual, ain't happening; man 1 systemd-nspawn ... OPTIONS ... --network-interface= Assign the specified network interface to the container. This will remove the specified interface from the calling namespace and place it in the container. When the container terminates, it is moved back to the host namespace. [...] Given what's actually going on, should be stated; --network-interface= Assign the specified network interface to the container. This will remove the specified interface from the calling namespace and place it in the container. When the container terminates, considering that the specified interface is not moved back to the host namespace, specific kernel module need to be reloaded to move it back to the host namespace. [...] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn network-interface
On Thu, 13.04.17 16:08, poma (pomidorabelis...@gmail.com) wrote: > Hello > > Regaining of the network-interface, as is stated in the manual, ain't > happening; > man 1 systemd-nspawn > ... > OPTIONS > ... > --network-interface= > Assign the specified network interface to the container. > This will remove the specified interface from the calling namespace and > place it in the container. > When the container terminates, > it is moved back to the host namespace. [...] > > Given what's actually going on, should be stated; > --network-interface= > Assign the specified network interface to the container. > This will remove the specified interface from the calling namespace and > place it in the container. > When the container terminates, > considering that the specified interface is not moved back to the host > namespace, > specific kernel module need to be reloaded to move it back to the host > namespace. [...] Upgrade your kernel! This all works correctly on current kernels: network interfaces will now safely migrate back to the parent namespace when a network namespace dies. We usually don't document bugs in other software in systemd, but instead ask people to run current systemd only in conjunction with somewhat current kernels. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn network-interface
On 17.04.2017 11:59, Lennart Poettering wrote: > On Thu, 13.04.17 16:08, poma (pomidorabelis...@gmail.com) wrote: > >> Hello >> >> Regaining of the network-interface, as is stated in the manual, ain't >> happening; >> man 1 systemd-nspawn >> ... >> OPTIONS >> ... >> --network-interface= >> Assign the specified network interface to the container. >> This will remove the specified interface from the calling namespace and >> place it in the container. >> When the container terminates, >> it is moved back to the host namespace. [...] >> >> Given what's actually going on, should be stated; >> --network-interface= >> Assign the specified network interface to the container. >> This will remove the specified interface from the calling namespace and >> place it in the container. >> When the container terminates, >> considering that the specified interface is not moved back to the host >> namespace, >> specific kernel module need to be reloaded to move it back to the host >> namespace. [...] > > Upgrade your kernel! This all works correctly on current kernels: > network interfaces will now safely migrate back to the parent > namespace when a network namespace dies. > > We usually don't document bugs in other software in systemd, but > instead ask people to run current systemd only in conjunction with > somewhat current kernels. > > Lennart > There you go! # hostnamectl | grep -v 'host\|ID' Icon name: computer-desktop Chassis: desktop Operating System: Fedora 26 (Twenty Six) CPE OS Name: cpe:/o:fedoraproject:fedora:26 Kernel: Linux 4.11.0-0.rc7.git0.1.fc26.x86_64 Architecture: x86-64 # machinectl No machines. # nmcli device | grep enp3s0 enp3s0 ethernet unmanaged -- # networkctl | grep enp3s0 WARNING: systemd-networkd is not running, output will be incomplete. 9 enp3s0 ether n/a unmanaged # systemd-nspawn --version systemd 233 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN default-hierarchy=hybrid # systemd-nspawn --boot --machine fedora25 --image fedora25.raw --network-interface=enp3s0 Spawning container fedora25 on /[...]/fedora25.raw. Press ^] three times within 1s to kill container. systemd 231 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization systemd-nspawn. Detected architecture x86-64. Welcome to Fedora 25 (Twenty Five)! Set hostname to coconut. [...] Fedora 25 (Twenty Five) Kernel 4.11.0-0.rc7.git0.1.fc26.x86_64 on an x86_64 (console) coconut login: root Password: Last login: [...] on console # hostnamectl | grep -v 'host\|ID' Icon name: computer-container Chassis: container Virtualization: systemd-nspawn Operating System: Fedora 25 (Twenty Five) CPE OS Name: cpe:/o:fedoraproject:fedora:25 Kernel: Linux 4.11.0-0.rc7.git0.1.fc26.x86_64 Architecture: x86-64 # nmcli device | grep enp3s0 Error: NetworkManager is not running. # networkctl | grep enp3s0 9 enp3s0 ether routableconfigured # poweroff [...] Powering off. Container fedora25 has been shut down. # nmcli device | grep enp3s0 # networkctl | grep enp3s0 WARNING: systemd-networkd is not running, output will be incomplete. # systemd-nspawn --boot --machine fedora25 --image fedora25.raw --network-interface=enp3s0 Spawning container fedora25 on /run/media/test/cb2b679b-fac2-4e92-86d2-665bbe29f2c4/nspawn/fedora25.raw. Press ^] three times within 1s to kill container. Failed to resolve interface enp3s0: No such device [...] Feel free to ask, I can do more tests. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn network interface name collisions
Hi, if i understnd this correct, the network interface names (veth and macvlan) are created with the frist 11 Caracters from the Containername (Machinename). Now if you use similar names for conatiners, like com.$company.$devision.$name1 com.$company.$devision.$name2 com.$company.$devision.$name3 the network device name handling is broken. I tryed to prefix the machinename with a uuid (uuidgen) but the the names are to long. Why not using a 11 Caracter uuid / random for network interface names, and avoid all the naming trouble? regards Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn network interface name collisions
On Thu, 18.06.15 18:27, Florian Koch (florian.koch1...@gmail.com) wrote: > Hi, > > if i understnd this correct, the network interface names (veth and > macvlan) are created with the frist 11 Caracters from the > Containername (Machinename). IFNAMSIZ emposed by the Linux kernel is 16, and we need three chars for the prefix "ve-" and one for the trailing NUL byte. makes 12 chars. > > Now if you use similar names for conatiners, like > > com.$company.$devision.$name1 > com.$company.$devision.$name2 > com.$company.$devision.$name3 > > the network device name handling is broken. > > I tryed to prefix the machinename with a uuid (uuidgen) but the the > names are to long. > > Why not using a 11 Caracter uuid / random for network interface > names, and avoid all the naming trouble? Well, because we want to keep things easy to grok for users. If you type "ip link" and see the container names for the veth links, then that's certainly a lot more useful than seeing some random gibberish I'd be willing to make this configurable: --network-veth→ as it is now, host is called ve- and container side is called host0 --network-veth=foo→ creates a veth link with both sides named "foo" --network-veth=foo:bar→ host side called "foo", container side called "bar". At the same time we should open this up so that multiple links can be created, not just one. Happy to take a patch for that! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn network-interface doesn't return interface on container reboot
Hi Everyone. I have below trouble. I start my container with --network-interface option as below: ExecStart=/usr/bin/systemd-nspawn -M %i.%H --quiet --keep-unit --boot --link-journal=auto --network-veth *--network-interface=dummy6* --capability=CAP_NET_RAW --directory=/var/lib/container/%i Everything works fine but when I try to reboot my container the dummy6 is not returned back to host machine's namespace and my container fails to start next time. Only host machine reboot helps. Do we have some way to return the interface back to host's machine namespace even maybe manually. Thanks for help in advance! -- Dmitry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
