SDN labs not working on macOS with Docker Desktop. openvswitch module not found

[michele-segata]

Operating System

macOS Sonoma 14.6.1

Kathará Version

3.7.6

Bug Description

The SDN labs do not work because OpenVSwitch kernel modules are not found. In particular, this is the log found in the switch terminal:

++ ip addr add 20.0.1.1/24 dev eth2
++ /usr/share/openvswitch/scripts/ovs-ctl --system-id=random start
nice: cannot set niceness: Permission denied
Starting ovsdb-server.
Configuring Open vSwitch system IDs.
modprobe: FATAL: Module openvswitch not found in directory /lib/modules/6.10.4-linuxkit
Inserting openvswitch module ... failed!
rmmod: ERROR: ../libkmod/libkmod-module.c:1998 kmod_module_get_holders() could not open '/sys/module/bridge/holders': No such file or directory
rmmod: ERROR: Module unloading is not supported
removing bridge module ... failed!
++ ovs-vsctl add-br s1
--- End Startup Commands Log
!!! Executing other commands in background !!!
root@s1:/# 

This seems to be related with docker desktop. Starting from a certain version it seems like the openvswitch module is built in (I saw it here).
Indeed, by listing modules, openvswitch can be found

find /lib/modules | grep openvswitch
/lib/modules/6.1.0-26-rt-arm64/kernel/net/openvswitch
/lib/modules/6.1.0-26-rt-arm64/kernel/net/openvswitch/openvswitch.ko
/lib/modules/6.1.0-26-rt-arm64/kernel/net/openvswitch/vport-gre.ko
/lib/modules/6.1.0-26-rt-arm64/kernel/net/openvswitch/vport-vxlan.ko
/lib/modules/6.1.0-26-rt-arm64/kernel/net/openvswitch/vport-geneve.ko

but it cannot be loaded, because it is being searched in the wrong directory

modprobe openvswitch
modprobe: FATAL: Module openvswitch not found in directory /lib/modules/6.10.4-linuxkit

Steps To Reproduce

Simply run one of the emulations, for example:

cd Kathara-Labs/main-labs/sdn-openflow/pox/01-pox-controller
kathara lstart

Expected Behavior

The switch should simply load the kernel module and run.

Check Command Output

No response

[tcaiazzi]

Dear @michele-segata,

Thanks for reaching out and noticing the problem!

Probably, the ovs-ctl command searches for the openvswitch kernel module in the wrong path, supposing that it should be a loadable kernel module.

I'll further investigate the issue and I will come out with a solution as I find it.

[Skazza94]

Hi @michele-segata,
unfortunately, Docker made the openvswitch module a builtin one, meaning that the modprobe fails when loading the module.

Currently, there is no official solution neither from Docker nor from OpenVSwitch, but a simple workaround is to bypass the modprobe in the ovs-ctl script (and in any other that requires it).

I am attaching a patched version of the script that adds a --no-kernel flag to bypass the modprobes. Indeed, this is a temporary workaround, and we might update the Docker image with a better and less invasive solution.

GitHub does not allow to upload a bash script, so I renamed it in .txt:
ovs-ctl.txt

To use it:

• Rename from ovs-ctl.txt to ovs-ctl
• In each OpenVSwitch device in the Kathará lab, create the folder <switch_name>/usr/share/openvswitch/scripts (for example, mkdir -p s1/usr/share/openvswitch/scripts)
• Copy/Paste the patched ovs-ctl
• In the startups, before calling ovs-ctl, add a chmod +x /usr/share/openvswitch/scripts/ovs-ctl to give execute permissions (it is not assigned when copying files from the host) and add the --no-kernel flags to the commands

Result:

Let me know if this solution works. If so, we will plan to add a patch in the kathara/sdn image.

Cheers,
Mariano

[michele-segata]

Hi @Skazza94
Yep, that worked perfectly well. I just created my own Dockerfile which copies your patched ovs-ctl inside the container, then use that one to run the lab. I tried the 01-pox-controller example with the --no-kernel option and it worked perfectly.
Probably instead of using the --no-kernel option it is sufficient to detect whether the kernel module is built-in or not from within ovs-ctl, but you are the experts here! :)
If you come up with a patch, let me know. I'd be happy to test if for you.

[Skazza94]

Hi @michele-segata,
actually we found a smarter way to achieve the same. We will embed the patch in the Docker image soon.

Cheers,
Mariano.