Fedora Account System
Red Hat Associate
Red Hat Customer
Imported raw disk image VM and started get's allocated an IP address and default route set to host machine interface (192.168.122.1) Machine can resolve DNS names (via dnsmasq on host) but traffic is not NAT'ed so no external connections are possible The image is Ubuntu 24.04.04 image (was working on a Fedora 42 machine before being copied to new Fedora 44 install) Can ping both ways between host and VM. Reproducible: Always Steps to Reproduce: 1.import VM disk image into boxes 2.start vm 3.try and access internet Actual Results: All network requests to other than the host machine timeout Expected Results: Network requests to connect Additional Information: As a normal user `virsh net-list --all` shows no networks As root user `virsh net-list --all` shows the `default` network ``` # iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination DOCKER all -- anywhere anywhere ADDRTYPE match dst-type LOCAL Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination DOCKER all -- anywhere !localhost/8 ADDRTYPE match dst-type LOCAL Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 172.17.0.0/16 anywhere Chain DOCKER (2 references) target prot opt source destination ``` I don't see a MASQUERADE entry for the virbr0 interface and subnet
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.
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