Closed DamienRobert closed 8 years ago
hmm, ve-arch-test@if2
what kind of a strange name is that? where does the @
come from? how did you create the interface?
No idea! I just use systemd-nspawn -bnM arch-test
and systemd-nspawn creates the interface. On my laptop the interface has the same name, but the ID_NET_DRIVER=veth
is set up correctly there.
if you doo ethtool -i on the interface, what does it say?
(Meanwhile I have changed the name of the container)
$ ip a 4: ve-arch-contai@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether ba:7f:31:92:12:81 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 169.254.169.115/16 brd 169.254.255.255 scope link ve-arch-contai valid_lft forever preferred_lft forever inet 10.0.0.1/28 brd 10.0.0.15 scope global ve-arch-contai valid_lft forever preferred_lft forever inet6 fe80::b87f:31ff:fe92:1281/64 scope link valid_lft forever preferred_lft forever
(The connection is active because I have removed the condition Driver=veth from 80-container-ve.network)
$ sudo ethtool -i 've-arch-contai@if2' ethtool: bad command line argument(s)
$ sudo ethtool -i ve-arch-contai driver: veth version: 1.0 firmware-version: expansion-rom-version: bus-info: supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
So the veth driver is there, even through this is not reflected by udev. By the way about the strange name, from what I remember the '@foo' is used to declare aliases to an interface. I have no idea why there would be an alias there...
I figure the problem is with this line actually from your earlier dump:
Assertion 'udev_device' failed at src/libudev/libudev-device.c:126, function udev_device_get_driver(). Ignoring.
Not sure what's going on there... @teg you reworked that, any idea?
hmm, ve-arch-test@if2 what kind of a strange name is that? where does the @ come from? how did you create the interface?
OT: This is normal, I have the same names using network-macvlan or network-veth. Using Archlinux with latest everything
Same problem here with systemd 225. All was working fine with systemd 218. My containers has no more network with veth. Archlinux on host and containers. One container is working with macvlan interfaces but I have to configure them by hand: netctl refuses to see them.
Here is an example with veth:
On the host :
18: ve-ognanrecoted: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 1a:e8:50:ad:9f:c9 brd ff:ff:ff:ff:ff:ff inet 192.168.66.1/32 scope global ve-ognanrecoted valid_lft forever preferred_lft forever inet6 fe80::18e8:50ff:fead:9fc9/64 scope link valid_lft forever preferred_lft forever
On the container:
2: host0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 36:15:87:7b:9a:dd brd ff:ff:ff:ff:ff:ff inet 192.186.66.10/24 scope global host0 valid_lft forever preferred_lft forever inet6 fe80::3415:87ff:fe7b:9add/64 scope link valid_lft forever preferred_lft forever
For netctl in container, interface host0 doesn't exist.
More infos in container:
/sys/class/net see the host interfaces
$ ls /sys/class/net/ enp3s1f0 enp3s1f1 enp8s2 lo ve-ognanrecoted
But ip see the veth interface: $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: host0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 36:15:87:7b:9a:dd brd ff:ff:ff:ff:ff:ff inet 192.186.66.10/24 scope global host0 valid_lft forever preferred_lft forever inet6 fe80::3415:87ff:fe7b:9add/64 scope link valid_lft forever preferred_lft forever
It's impossible to ping host from container or container from host. Network unreachable.
More infos from host: $ udevadm test-builtin net_setup_link /class/net/ve-ognanrecoted calling: test-builtin === trie on-disk === tool version: 225 file size: 6656088 bytes header size 80 bytes strings 1714568 bytes nodes 4941440 bytes Load module index timestamp of '/etc/systemd/network' changed timestamp of '/usr/lib/systemd/network' changed Parsed configuration file /usr/lib/systemd/network/99-default.link Created link configuration context. ID_NET_DRIVER=veth Assertion 'udev_device' failed at src/libudev/libudev-device.c:126, function udev_device_get_driver(). Ignoring. Config file /usr/lib/systemd/network/99-default.link applies to device ve-ognanrecoted ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link Unload module index Unloaded link configuration context.
$ udevadm info /sys/class/net/ve-ognanrecoted P: /devices/virtual/net/ve-ognanrecoted E: DEVPATH=/devices/virtual/net/ve-ognanrecoted E: ID_NET_DRIVER=veth E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link E: IFINDEX=18 E: INTERFACE=ve-ognanrecoted E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ognanrecoted E: TAGS=:systemd: E: USEC_INITIALIZED=127718673102
Same message : Assertion 'udev_device' failed at src/libudev/libudev-device.c:126, function udev_device_get_driver(). Ignoring.
So, there was quite a fuckup with network namespaces in nspawn, which is fixed now in git. Closing this one hence, since I am confident this is fixed now. Feel free to file a new bug if the issue persists with the upcoming version of systemd.
This is similar to issue #395, but with systemd-224
On the host: $ ip a 4: ve-arch-test@if2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 8a:5f:a8:d4:9a:9e brd ff:ff:ff:ff:ff:ff link-netnsid 0 On the container: 2: host0@if4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state LOWERLAYERDOWN group default qlen 1000 link/ether 92:50:d9:05:b8:47 brd ff:ff:ff:ff:ff:ff link-netnsid 0
Indeed networkd is not managing ve-arch-test, but according to networkctl80-container-ve.network it should!
$ networkctl 4 ve-arch-test ether off unmanaged
Here are some more infos: $ udevadm test-builtin net_setup_link /class/net/ve-arch-test calling: test-builtin === trie on-disk === tool version: 224 file size: 7049244 bytes header size 80 bytes strings 1762716 bytes nodes 5286448 bytes Load module index timestamp of '/etc/systemd/network' changed Parsed configuration file /usr/lib/systemd/network/99-default.link Created link configuration context. ID_NET_DRIVER=veth Assertion 'udev_device' failed at src/libudev/libudev-device.c:126, function udev_device_get_driver(). Ignoring. Config file /usr/lib/systemd/network/99-default.link applies to device ve-arch-test ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link Unload module index Unloaded link configuration context.
$ udevadm info /sys/class/net/ve-arch-test P: /devices/virtual/net/ve-arch-test E: DEVPATH=/devices/virtual/net/ve-arch-test E: IFINDEX=4 E: INTERFACE=ve-arch-test E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/ve-arch-test E: TAGS=:systemd: E: USEC_INITIALIZED=326874353 [so it looks like the ID_NET_DRIVER=veth is missing]
$ uname -a Linux feanor 4.1.5-1-ARCH #1 SMP PREEMPT Tue Aug 11 15:41:14 CEST 2015 x86_64 GNU/Linux
This is with systemd-224. On my laptop the same setup works flawlessly, and indeed this time udevadm info /sys/class/net/ve-arch-test gives me 'ID_NET_DRIVER=veth'
If I copy 80-container-ve.network to /etc/systemd/network and remove the Driver=veth there, systemd-networkd configures ve-arch-test and the network works on the container. So this looks like a problem in udev somewhere, I'll be happy to give more infos.