Switching from CNI to Netavark on Fedora CoreOS non-destructively?

Ask Fedora
,
1

I need to update my network backend from CNI to Netavark to prepare for the release of Fedora CoreOS 40 and the introduction of Podman v5.

The only things I can find online say that I need to run podman system reset but that is destructive and will remove all of my current containers (tolerable) and images (not desirable) and apparently volumes (not tolerable). I have been playing around with the configuration files on a test steup and it looks like I can force the use of Netavark by settings network_backend = "netavark" in /etc/containers/containers.conf. This immediately causes podman info | grep "networkBackend" to indicate Netavark is in use and still seems to be the case after a reboot but is there a way to know it really worked and I am not going to be surprised at some point in the future?

Thanks for any advice.

Doug

2

Added podman

3

This is a good question indeed. I linked it in Podman v5 breaking changes · Issue #1629 · coreos/fedora-coreos-tracker · GitHub but you should reach out to podman folks, probably on Matrix to get suggestions.

If you get an answer, we’ll gladly incorporate it into the announcement.

4

I received a few responses.

First, I was told to take a look at Migration from CNI to netavark · containers/podman · Discussion #20919 · GitHub

I responded with the following:

Thanks! That leaves me a little uncertain still since I notice if I do perform the podman system reset and leave the setting for network_backend = "" I will get a “netavark” networkBackend BUT if I just change the value of network_backend to “netavark” and reboot, it changes, but then if I remove that change and leave it as “” again, it goes back to CNI on the next reboot. This is what makes me uncertain whether it really is making the change because of the different behaviors.

I have tried to determine if there are other files, directories to be removed but I can find nothing else on the system that appears or disappears related to the two different approaches.

This received the following response:

podman info is not lying. It uses whatever it says there. The issue is if you do revert the conf setting it falls back to the auto detection logic which first reads the “defaultNetworkBackend” file (which acts as cache file) in the graph root, if this does not exist it will run the auto detection logic.

Because we did not want to break anyone when switching from 3.X to 4.X it assumes if you have existing images/containers/networks that we have to use CNI for compatibility reasons.

Of course, when you update to 5.0 without CNI support then no such detection logic will run as it only uses netavark.