Problem with vnet network device, possible race condition

Ask Fedora
, ,
1

I don’t know if this is a bug or a configuration issue. Any help would be appreciated.

Summary of the problem

I have a system (that is assigned a static IP from the router) that is receiving a different IP address after waking from sleep. It only happens when my virtual machine created in Virtual Machine Manager is running before the system sleeps. The virtual machine is connected to a bridge network so that it is on the same network of the system. It appears the the vnet0 network device is requesting a dynamic address and assigning it to the bridge network before the ethernet device can.

Details of the problem

I’m running on Bazzite, although, I believe the problem may extend across any variant of Fedora. I have used the ujust enable-virtualization command and installed the qemu extension. I then created a bridge with my ethernet device as a slave with these instructions Network bridge - ArchWiki.

When the system wakes from sleep after running a virtual machine connected to this bridge, the vnet0 network takes precedence over the ethernet network.

I have an OPNSense router applying a static IPv4/6 address to the system. Running ip a on the system shows the same MAC address for the bridge (br0) and the ethernet device (enp…), but a different MAC for the vnet0 device. I can see on the router that the MAC from the vnet0 device is getting a leased address. This is the address that gets applied to the bridge, even though the bridge should have a static address according to its MAC address.

Issue this causes

When I wake the system the IP address is different, even though it should be static. I have firewall rules to ensure only specific DNS servers are allowed. This causes loss of internet connectivity only on the system (VM has connectivity) when resuming from sleep.

Troubleshooting

I can bring the static IP address back by running nmcli connection up bridge-br0, but then it destroys the vnet0 network and the virtual machine has no connection. I can restore this connection by suspending and resuming the virtual machine.

2

This appears a timing issue, and the bridge should never be activated before the standard interface is up and connected.

One solution would be to always shut down the VM before allowing the host to sleep (especially since this also sleeps the VM).

There also should be a way for the system to enforce that the bridge is not enabled and activated before the interface is activated when waking up but I cannot give first hand details since I do not use networking in that manner.

Most systems use NetworkManager for network connections and it may be necessary to force NetworkManager to activate the interface before enabling the bridge when waking from sleep.

After a bit of searching I wound up with searching for Nmcli autoconnect-priority which led to nm-settings-nmcli: NetworkManager Reference Manual

Possibly this will help.

3

Compare the output for working and faulty states:

nmcli connection show
4

Thanks for the input, the results of this command before and after are the same. The network devices are working, it is just that the IP of my bridge interface is not as expected with a static assignment from the router.

5

Thanks for the response, but I’m not sure how to handle this as the VNET device is really just an automatically generated temporary interface that gets dismantled when shutting down/suspending the VM. I was trying to find if there is a configuration for this VNET but no luck finding it yet.

6

This looks like a race condition possibly caused by misconfiguration.
Let’s inspect the runtime state, logs and configs when the issue happens:

PAGER= nmcli
journalctl --no-pager -S -10m
sudo head -v -n -0 /etc/NetworkManager/system-connections/*

If the output is too large, you can use some sharing service like pastebin.com.