This shows our test system running a simple Ubuntu 20.04 host did get working network on all Oracle images, privileged or not, cloud or not.
So far the majority of users who reported issues with this have been found to run kernels that have broken network interface ownership which then break network manager.
To see if thatâs whatâs affecting you, check ls -lh /sys/class/net/ inside your container.
It should look like:
stgraber@shell01:~$ ls -lh /sys/class/net/
total 0
lrwxrwxrwx 1 root root 0 Jul 18 16:10 eth0 -> ../../devices/virtual/net/eth0
lrwxrwxrwx 1 root root 0 Jul 18 16:10 lo -> ../../devices/virtual/net/lo
stgraber@shell01:~$
If eth0 is owned by nobody:nogroup, this is an indication that your kernel doesnât properly handled network interface ownership in unprivileged kernels and that NetworkManager will therefore refuse to use it.
In this system, both the container and the host system are Oracle 8. As mentioned, using privileged container does workaround the issue and container gets IP address successfully from DHCP in the privileged case.
If the Oracle 8 container is unprivileged then it does indeed have ânobodyâ as the owner of the virtual eth0, as shown below, and then is unable to get a DHCP address.
Results for each case are shown below.
Container (privileged)
[ubuntu@o83sv2 ~]$ lxc exec ora83d14 bash
[root@ora83d14 ~]# ls -lh /sys/class/net
total 0
lrwxrwxrwx. 1 root root 0 Jul 19 03:40 eth0 â âŠ/âŠ/devices/virtual/net/eth0
lrwxrwxrwx. 1 root root 0 Jul 19 03:40 lo â âŠ/âŠ/devices/virtual/net/lo
[root@ora83d14 ~]# cat /etc/oracle-release
Oracle Linux Server release 8.4
[root@ora83d14 ~]# uname -a
Linux ora83d14 5.4.17-2102.203.5.el8uek.x86_64 #2 SMP Mon Jun 28 16:44:26 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux
[root@ora83d14 ~]#
Container (unprivileged):
[root@oel83d12 rules.d]# ls -lh /sys/class/net
total 0
lrwxrwxrwx. 1 nobody nobody 0 Jul 19 08:32 eth0 â âŠ/âŠ/devices/virtual/net/eth0
lrwxrwxrwx. 1 root root 0 Jul 19 08:32 lo â âŠ/âŠ/devices/virtual/net/lo
[root@oel83d12 rules.d]# uname -a
Linux oel83d12 5.4.17-2102.203.5.el8uek.x86_64 #2 SMP Mon Jun 28 16:44:26 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux
[root@oel83d12 rules.d]# cat /etc/oracle-release
Oracle Linux Server release 8.4
[root@oel83d12 rules.d]#
Right, so in this setup, NM will indeed not work. Your best bet short of finding a way to run a kernel with the needed fix is to manually switch over to something other than NM for your network configuration.
@trystan I did reach out to Avi Miller (@AviAtOracle) via Twitter, although he is no longer the Product Director for Oracle Linux, he would be able comment on it and/or to route it internally at Oracle. Havenât heard back yet from Avi but itâs not even been 24 hours yet.
Thanks so much for getting that info! Much appreciated.
I decided to attempt booting the elrepo mainline kernel and sure enough the appropriate permissions were applied and NM acted on the interface.
However, Iâm noticing that with a manually created bridge, the container will not pull an IP (NM says connecting waiting for IP indefinitely) if the host has an IP assigned to the same bridge.
As soon as I set the hostâs ipv4 address on the bridge to âdisabledâ the container is able to assign an IP.
For devices with a single interface this presents an issue as the only two options to bring the container into the same IP space as the host (macvlan or bridged interface) are not available.
What platform are you running on?
This behavior of only the host or a container being able to get an address usually points towards the network switch filtering MAC addresses.
So Iâm assuming that âteamâ is some kind of wrapper around standard Linux bonding. All that is fine. If there is MAC filtering, itâs likely outside of your system (done by the physical switch or a vSwitch in a virtual environment).
I swapped from redhatâs new âteamâ feature to the legacy âbondingâ using the closest comparable settings and this resolved it. Both host and container are now happily sharing the interface via a bridge.
As for the NM inside the LXC container: UEK kernel needs privileged mode, elrepo mainline 5.13 kernel does not. Hopefully I can convince someone at Oracle to add that PR to their kernel.
Hey folks. as @Gilbert_Standen mentioned, Iâm no longer an Oracle Linux PM, but I did send this thread to the current PM for him to review with our engineering team.
This has been logged internally as bug 33141684. If any of you have a paid Oracle Linux support subcription, I recommend opening an SR for this issue so that we get some customers attached to the bug (which raises its priority).
Can someone please shed some light on how this is a solution? Iâm not really certain how quickly I can see this pull request making itâs way to my lxc host kernel.
Iâm running some CentOS 8 containers. Even with static IPs set inside the container, I have to run ifup after each restart. Which is REALLY inconvenient when you need a container to start up and provide DHCP and DNS to your networkâŠ
Hello.
After updating almalinux (RHEL based) in LXC I faced the same problem. After the update, the NetworkManager was be installed. (Before that was are network-scripts for managing network) Solution for me:
Iâve managed to create a cloud-init bootcmd section which automatically works around this issue for RHEL8 devilled containers⊠Disable NetworkManger which is ignoring veth derived devices (e.g. eth0) and then bring up the eth0 manually and then install and enable old school networking which does work.