systemd-networkd fails when using physical(!) Incus network #48
Comments
|
What container image are you using for this? |
|
I'm glad I kept the VMs I was playing around with. Yes, udevd runs. Hopefully the following info helps: Image name: Note, when privileged mode is enabled (undesirable) for the container, the described problem disappears: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To be honest, I'm not sure where to file this bug... lxc, Incus, or systemd? Would love to hear your thoughts on the issue. For now I have a usable workaround (using ifupdown, details below), but it would be helpful if this bug would be fixed, so everybody can benefit from things working out-of-the-box.
EDIT: I probably should've filed this under lxc/incus instead of zabbly/incus. Sorry!
EDIT2: Incus version: 6.0.1 LTS
Background:
I'm running an Incus host in QEMU/KVM. Hence, I've added multiple virtual NICs to the Incus host, so I can give each container its own NIC, in order to avoid running into issues related to things like 'port security' and multiple MAC addresses originating from the same NIC (as would be the case with macvlan).
On the Incus host:
incus network create testphys0 -t physical parent=enp9s0Then I assigned the physical 'testphys0' Incus network to a regular Debian 12 (bookworm) system container.
Or, in one step (ignoring the above):
incus config device add testcontainer eth0 nic nictype=physical parent=enp9s0The problem:
In the container:
The
systemd-networkddaemon is NOT assigning an IP address to the eth0 interface.I've tried using a static IP as well as DHCP. There's no difference in symptoms.
The eth0 interface is UP but is NOT being assigned an IP address.
The
networkctlcommand shows the following:The
ip -br acommand shows:(Disabling IPv6 doesn't matter either.)
I've also included the systemd-networkd logs (with debugging output).
See further below.
A dirty, undesirable workaround is to run the container in privileged mode, but for security reasons that's NOT a viable solution. For those interested in a better (safer) workaround, see below.
Now the question:
Is this a bug in systemd-networkd or somewhere else?
Workaround (or solution), for others reading this:
This is a workaround which does NOT require the container to be in 'privileged mode':
This will disable systemd-networkd and it will remove the systemd-resolved package. The systemd-resolved package is removed by installing resolvconf (which we will need if we want to configure DNS settings via the ifupdown interfaces config file).
Note, it seems you must use 'auto eth0' and NOT 'allow-hotplug eth0', otherwise it won't work. That might be because ifupdown's networking scripts won't actually be triggered by the hotplug (udev) event because the interface is being renamed when the container is starting up, meaning the hotplug event was missed (the interface had a different name at the moment of the udev event).
Other debugging details:
If we give the container a bridged Incus network, like 'incusbr0', there's no issue at all.
The problem only occurs if we assign a physical Incus network to the container, as shown at the beginning of this post.
I've read lxc issue #2278 and that made me check AppArmor.
For completeness sake: installing apparmor and running 'aa-teardown' doesn't make a difference; if we subsequently run 'systemctl restart systemd-networkd', the symptoms stay the same.
Just to rule it out, I tried changing the Incus VM's virtual NIC driver from virtio to e1000e, without any noticeable difference.
Logs:
Logs from the (non-privileged) container, with SYSTEMD_LOG_LEVEL=debug enabled:
# journalctl -eu systemd-networkdPS:
You've been doing good work Stéphane! Much love ❤️
The text was updated successfully, but these errors were encountered: