You are not logged in.
I use virt-manager and before networking worked flawlessly, now all my guests can't obtain an IP from the virtual NAT.
I tried disabling firewalld and use iptables for libvirt as suggested in the wiki but nothing works still.
I don't use NetworkManager or systemd-networkd since i use a static ip for my host, never needed it before either way.
sudo virsh net-dumpxml default
<network>
<name>default</name>
<uuid>e64f9d36-ad52-4aa6-badd-dbed9bd2de6e</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:22:ca:0f'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
3: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:5b:15:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.100.255 scope global virbr1
valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:22:ca:0f brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
Offline
I'm seeing something similar, it seems to have broken sometime in the last few days. No configuration changes other than package updates but both guest machines (one windows, one linux) are having network issues. The initial symptom of not being assigned an IP address was the same. I set the IP manually on a host and was then able to ping the host system's bridge address (192.168.122.1), but nothing else. I also tried temporarily disabling the host machine's firewall to see if it was a rules issue - no luck. My settings look the same as yours aside from the different UUIDs/MACs, and I only have the default bridge network virbr0. I do use NetworkManager as well as systemd-resolved.
I'm not sure why the guests aren't getting addresses from dnsmasq if they're able to ping the host system when manually configured. The dnsmasq process looks to be starting up fine. And I'm also not sure why I can ping the host system but nothing is getting forwarded to other IPs even if the firewall is completely disabled. That's why it really felt like a firewall issue, but it still happens while firewalld is down:
$ sudo firewall-cmd --state
not running
journalctl -u libvirtd shows no errors other than the virConnectGetAllDomainStat failure which has always been there:
Jul 23 13:18:00 pluto systemd[1]: Starting libvirt legacy monolithic daemon...
Jul 23 13:18:00 pluto systemd[1]: Started libvirt legacy monolithic daemon.
Jul 23 13:18:01 pluto dnsmasq[1554]: started, version 2.90 cachesize 150
Jul 23 13:18:01 pluto dnsmasq[1554]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
Jul 23 13:18:01 pluto dnsmasq-dhcp[1554]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h
Jul 23 13:18:01 pluto dnsmasq-dhcp[1554]: DHCP, sockets bound exclusively to interface virbr0
Jul 23 13:18:01 pluto dnsmasq[1554]: reading /etc/resolv.conf
Jul 23 13:18:01 pluto dnsmasq[1554]: using nameserver 127.0.0.53#53
Jul 23 13:18:01 pluto dnsmasq[1554]: read /etc/hosts - 15 names
Jul 23 13:18:01 pluto dnsmasq[1554]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 names
Jul 23 13:18:01 pluto dnsmasq-dhcp[1554]: read /var/lib/libvirt/dnsmasq/default.hostsfile
Jul 23 13:18:04 pluto dnsmasq[1554]: reading /etc/resolv.conf
Jul 23 13:18:04 pluto dnsmasq[1554]: using nameserver 127.0.0.53#53
Jul 23 13:18:04 pluto dnsmasq[1554]: reading /etc/resolv.conf
Jul 23 13:18:04 pluto dnsmasq[1554]: using nameserver 127.0.0.53#53
Jul 23 13:18:42 pluto libvirtd[1426]: libvirt version: 10.5.0
Jul 23 13:18:42 pluto libvirtd[1426]: hostname: pluto
Jul 23 13:18:42 pluto libvirtd[1426]: this function is not supported by the connection driver: virConnectGetAllDomainStat
It looks like all my docker containers are having a similar issue. They can ping the bridge IP but can't reach anything else. However, I'm not sure if those were working before I began troubleshooting this issue. I might roll back my system if I have time later.
$ ip addr show docker0
8: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ad:91:c8:a2 brd ff:ff:ff:ff:ff:ff
inet 10.80.0.1/24 brd 10.80.0.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:adff:fe91:c8a2/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
from within a docker container:
a8964fa94796:/# ping 10.80.0.1
PING 10.80.0.1 (10.80.0.1) 56(84) bytes of data.
64 bytes from 10.80.0.1: icmp_seq=1 ttl=64 time=0.110 ms
64 bytes from 10.80.0.1: icmp_seq=2 ttl=64 time=0.140 ms
^C
--- 10.80.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1017ms
rtt min/avg/max/mdev = 0.110/0.125/0.140/0.015 ms
a8964fa94796:/# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2029ms
Offline
It seems to be working now.
I must not be fully understanding how firewalld/nftables work. Following these steps on the forum got connectivity back, at least temporarily. It gives me a direction to look into, at least!
Offline
I've reinstalled my whole system, since I assumed I might've messed something up with my system's networking, i also dont use firewalld,
I can also ping my bridge and I can configure my guest with no response from the host's DHCP server, and yes docker is having the same issue too.
I'm assuming its a problem with dnsmasq or the likes, no errors at all from docker or libvirtd.
I'll test it again once i finish setting up my system.
Offline
The root cause for me was having the firewalld and nftables services both enabled. According to the thread I linked before, even though nftables wasn't 'running', it started briefly on each boot and applied restrictive default rules that broke my bridges. Disabling the nftables service fixed the problem across reboots. I'm not sure if that got enabled randomly or if the rules it applied were tweaked, but the issue is solved now (and I still have a firewall, which is nice). Hope your reinstall goes well
Offline