Bug 2466836

A fresh build from a Ubuntu install iso also fails to connect while trying to locate mirrors.

Can you please attach the XML definition of the VM? Thanks.

Can you please attach the XML definition of the VM? Thanks.

Created attachment 2139676 [details]
XML definition of VM

Please let me know if you need anything else, or have any temporary workaround suggestions as I could really do with having this VM working next week.

Thanks

VM is qemu:///session created by gnome-boxes. network config is:

<interface type="bridge">
  <mac address="52:54:00:87:6a:5e"/>
  <source bridge="virbr0"/>
  <model type="virtio"/>
  <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>

Does stopping the VM, then restarting the 'default' network make a difference? sudo virsh net-destroy default ; sudo virsh net-start default

Nowadays libvirt should be using nftables by default IIRC

With boxes running and the VM shutdown if I run the command to restart the default network I get the following:

$ sudo virsh net-destroy default ; sudo virsh net-start default
Place your finger on the fingerprint reader
Network default destroyed

error: Failed to start network default
error: error creating bridge interface virbr0: File exists


The iptables command is setup with alternatives to point to the nftables binary (usr/bin/xtables-nft-multi)

I'm just applying the latest updates and rebooting so I'll test again when it's back up

Something really strange is going on now.

The VM is not even getting a 192.168.122.x address and I can't see dnsmasq running (which was running and handing out dhcp addresses when I opened the issue)

I have run dnf reinstall for

- libvirt-deamon
- libvirt-daemon-common
- libvirt-daemon-common-network


Just to make sure everything is as it should be (but the only file I touched was /usr/share/libvirt/networks/default.xml to add mode="nat" to the forward element when I first hit the problem, and I have since removed that).

Even after a clean reboot it's not starting dnsmasq.

I have found this in the logs

-- Boot c2c2216d20be4070a37512e76b93f22b --
May 10 19:20:21 razor-crest systemd[1]: Starting virtnetworkd.service - libvirt network daemon...
May 10 19:20:21 razor-crest systemd[1]: Started virtnetworkd.service - libvirt network daemon.
May 10 19:20:21 razor-crest virtnetworkd[6905]: libvirt version: 12.0.0, package: 3.fc44 (Fedora Project, 2026-01-26-10:19:53, )
May 10 19:20:21 razor-crest virtnetworkd[6905]: hostname: razor-crest
May 10 19:20:21 razor-crest virtnetworkd[6905]: internal error: Network is already in use by interface virbr0
May 10 19:20:54 razor-crest virtnetworkd[6905]: internal error: Network is already in use by interface virbr0
May 10 19:24:03 razor-crest systemd[1]: Stopping virtnetworkd.service - libvirt network daemon...
May 10 19:24:03 razor-crest systemd[1]: virtnetworkd.service: Deactivated successfully.
May 10 19:24:03 razor-crest systemd[1]: Stopped virtnetworkd.service - libvirt network daemon.

I'm wondering if network manager is somehow standing up a virbr0 before virtnetworkd is starting so it's clashing?

removing /etc/NetworkManager/system-connections/virbr0 has got me back to where we started, in that the VM now gets assigned a 192.168.122.x address but still no NAT access to the outside world

nft list ruleset has this block, which to me implies that it should be allowing guest_nat (but I'll be honest I've not played with nft at all yet)

...
table ip libvirt_network {
	chain forward {
		type filter hook forward priority filter; policy accept;
		counter packets 3576 bytes 276910 jump guest_cross
		counter packets 3576 bytes 276910 jump guest_input
		counter packets 3576 bytes 276910 jump guest_output
	}

	chain guest_output {
		ip saddr 192.168.122.0/24 iif "virbr0" counter packets 44 bytes 2704 accept
		iif "virbr0" counter packets 0 bytes 0 reject
	}

	chain guest_input {
		oif "virbr0" ip daddr 192.168.122.0/24 ct state established,related counter packets 0 bytes 0 accept
		oif "virbr0" counter packets 0 bytes 0 reject
	}

	chain guest_cross {
		iif "virbr0" oif "virbr0" counter packets 0 bytes 0 accept
	}

	chain guest_nat {
		type nat hook postrouting priority srcnat; policy accept;
		ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 7 bytes 440 return
		ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return
		meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
		meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
		ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade
	}
}
...


I've attached the full output

Created attachment 2140655 [details]
output of nft list ruleset

OK, I've made some progress

When I setup the machine I installed the Docker Engine using the full instructions with here:

- https://docs.docker.com/engine/install/fedora/

I believe the problem is an interaction between the firewall rules Docker installs and the libvirt rules (should be visible in the nft list ruleset file I attached yesterday). To verify this I disabled both the docker.service and the docker.socket and rebooted. After the reboot the VM works as expected and can reach the Internet via the default network.

I will see if I can open an issue against Docker Engine and point them at this issue. I'll leave this open for now as a pointer for others and because the fix may come from either side.

Docker engine issue: https://github.com/moby/moby/issues/52612

Manually forcing Docker to use nftables mode appears to fix things

https://docs.docker.com/engine/network/firewall-nftables/

(In reply to hardillb from comment #14)
> Manually forcing Docker to use nftables mode appears to fix things
> 
> https://docs.docker.com/engine/network/firewall-nftables/

Yes, unfortunately the incompatibility with Docker still using iptables is a known issue:

  https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables#Known_issue:_docker

It is good to know Docker is finally introducing nftables support.

Aside from configuring docker with its experimental nftables backend, other workarounds available are

 * Switch libvirt back to use iptables
 * Use podman instead of docker