title: "Libvirt, dnsmasq, QUEMU/KVM : default network dhcp not working (Page 2) / Networking, Server, and Protection / Arch Linux Forums"
source: https://bbs.archlinux.org/viewtopic.php?id=273243&p=2
author:
published:
created: 2025-09-02
description:
tags:
- HelpToolybird
Member
Registered: 2017-09-30
Posts: 85
> The status looks like this:
Hmm, looks basically fine. In my case I'm using systemd-networkd and systemd-resolved so my output is slightly different. It would be interesting to see a few other logs for comparison. Here's my "journalctl -b -u libvirtd" output immediately after boot:
Jan 29 06:55:03 ryzen systemd[1]: Starting Virtualization daemon...
Jan 29 06:55:03 ryzen systemd[1]: Started Virtualization daemon.
Jan 29 06:55:04 ryzen dnsmasq[1259]: started, version 2.86 cachesize 150
Jan 29 06:55:04 ryzen dnsmasq[1259]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cr>
Jan 29 06:55:04 ryzen dnsmasq-dhcp[1259]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h
Jan 29 06:55:04 ryzen dnsmasq-dhcp[1259]: DHCP, sockets bound exclusively to interface virbr0
Jan 29 06:55:04 ryzen dnsmasq[1259]: reading /etc/resolv.conf
Jan 29 06:55:04 ryzen dnsmasq[1259]: using nameserver 127.0.0.53#53
Jan 29 06:55:04 ryzen dnsmasq[1259]: read /etc/hosts - 3 addresses
Jan 29 06:55:04 ryzen dnsmasq[1259]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Jan 29 06:55:04 ryzen dnsmasq-dhcp[1259]: read /var/lib/libvirt/dnsmasq/default.hostsfile
Jan 29 06:57:03 ryzen systemd[1]: libvirtd.service: Deactivated successfully.
Jan 29 06:57:03 ryzen systemd[1]: libvirtd.service: Unit process 1259 (dnsmasq) remains running after unit stopped.
Jan 29 06:57:03 ryzen systemd[1]: libvirtd.service: Unit process 1260 (dnsmasq) remains running after unit stopped.
Here's the same but after booting a VM:
Jan 29 07:41:09 ryzen systemd[1]: libvirtd.service: Found left-over process 1259 (dnsmasq) in control group while starting unit. Ignoring.
Jan 29 07:41:09 ryzen systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Jan 29 07:41:09 ryzen systemd[1]: libvirtd.service: Found left-over process 1260 (dnsmasq) in control group while starting unit. Ignoring.
Jan 29 07:41:09 ryzen systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Jan 29 07:41:09 ryzen systemd[1]: Starting Virtualization daemon...
Jan 29 07:41:09 ryzen systemd[1]: Started Virtualization daemon.
Jan 29 07:41:09 ryzen dnsmasq[1259]: read /etc/hosts - 3 addresses
Jan 29 07:41:09 ryzen dnsmasq[1259]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Jan 29 07:41:09 ryzen dnsmasq-dhcp[1259]: read /var/lib/libvirt/dnsmasq/default.hostsfile
Jan 29 07:43:23 ryzen dnsmasq-dhcp[1259]: DHCPDISCOVER(virbr0) 52:54:00:22:e2:25
Jan 29 07:43:23 ryzen dnsmasq-dhcp[1259]: DHCPOFFER(virbr0) 192.168.122.87 52:54:00:22:e2:25
Jan 29 07:43:23 ryzen dnsmasq-dhcp[1259]: DHCPREQUEST(virbr0) 192.168.122.87 52:54:00:22:e2:25
Jan 29 07:43:23 ryzen dnsmasq-dhcp[1259]: DHCPACK(virbr0) 192.168.122.87 52:54:00:22:e2:25 archiso
Jan 29 07:46:27 ryzen systemd[1]: libvirtd.service: Deactivated successfully.
Jan 29 07:46:27 ryzen systemd[1]: libvirtd.service: Unit process 1259 (dnsmasq) remains running after unit stopped.
Jan 29 07:46:27 ryzen systemd[1]: libvirtd.service: Unit process 1260 (dnsmasq) remains running after unit stopped.
Jan 29 07:46:27 ryzen systemd[1]: libvirtd.service: Consumed 1.157s CPU time.
Here's "journalctl -b -g virbr0"
Jan 29 06:55:04 ryzen systemd-networkd[835]: virbr0: Link UP
Jan 29 06:55:04 ryzen dnsmasq-dhcp[1259]: DHCP, sockets bound exclusively to interface virbr0
Jan 29 07:42:23 ryzen kernel: virbr0: port 1(vnet0) entered blocking state
Jan 29 07:42:23 ryzen kernel: virbr0: port 1(vnet0) entered disabled state
Jan 29 07:42:23 ryzen kernel: virbr0: port 1(vnet0) entered blocking state
Jan 29 07:42:23 ryzen kernel: virbr0: port 1(vnet0) entered listening state
Jan 29 07:42:25 ryzen kernel: virbr0: port 1(vnet0) entered learning state
Jan 29 07:42:27 ryzen kernel: virbr0: port 1(vnet0) entered forwarding state
Jan 29 07:42:27 ryzen kernel: virbr0: topology change detected, propagating
Jan 29 07:42:27 ryzen systemd-networkd[835]: virbr0: Gained carrier
Jan 29 07:43:23 ryzen dnsmasq-dhcp[1259]: DHCPDISCOVER(virbr0) 52:54:00:22:e2:25
Jan 29 07:43:23 ryzen dnsmasq-dhcp[1259]: DHCPOFFER(virbr0) 192.168.122.87 52:54:00:22:e2:25
Jan 29 07:43:23 ryzen dnsmasq-dhcp[1259]: DHCPREQUEST(virbr0) 192.168.122.87 52:54:00:22:e2:25
Jan 29 07:43:23 ryzen dnsmasq-dhcp[1259]: DHCPACK(virbr0) 192.168.122.87 52:54:00:22:e2:25 archiso
Jan 29 07:44:11 ryzen kernel: virbr0: port 1(vnet0) entered disabled state
Jan 29 07:44:11 ryzen kernel: virbr0: port 1(vnet0) entered disabled state
Jan 29 07:44:11 ryzen systemd-networkd[835]: virbr0: Lost carrier
Here's "iptables -nL"
Chain INPUT (policy ACCEPT)
target prot opt source destination
LIBVIRT_INP all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
LIBVIRT_FWX all -- 0.0.0.0/0 0.0.0.0/0
LIBVIRT_FWI all -- 0.0.0.0/0 0.0.0.0/0
LIBVIRT_FWO all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
LIBVIRT_OUT all -- 0.0.0.0/0 0.0.0.0/0
Chain LIBVIRT_FWI (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain LIBVIRT_FWO (1 references)
target prot opt source destination
ACCEPT all -- 192.168.122.0/24 0.0.0.0/0
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain LIBVIRT_FWX (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain LIBVIRT_INP (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
Chain LIBVIRT_OUT (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:68
Offline
Toolybird
Member
Registered: 2017-09-30
Posts: 85
Just found another report on reddit:
It seems there is a definite problem somewhere...
I can only assume some recent pkg updates in combination with certain conditions (new setups?) have introduced the problem.
Total speculation, but my top suspects would be systemd and/or networkmanager.
Offline
Arrowhead
Member
Registered: 2021-11-27
Posts: 7
That's interesting!
I have similar logs, but the DHCP part is completely missing:
Jan 29 06:56:04 astoria systemd[1]: Started Virtualization daemon.
Jan 29 06:56:04 astoria libvirtd[5193]: 2022-01-29 03:56:04.812+0000: 5193: info : libvirt version: 8.0.0
Jan 29 06:56:04 astoria libvirtd[5193]: 2022-01-29 03:56:04.812+0000: 5193: info : hostname: astoria
Jan 29 06:56:04 astoria libvirtd[5193]: 2022-01-29 03:56:04.812+0000: 5193: debug : virLogParseOutputs:1635 : outputs=3:file:/var/log/libvirt/libvirtd.log
Jan 29 06:56:04 astoria libvirtd[5193]: 2022-01-29 03:56:04.812+0000: 5193: debug : virLogParseOutput:1482 : output=3:file:/var/log/libvirt/libvirtd.log
Jan 29 06:56:04 astoria dnsmasq[1344]: read /etc/hosts - 9 addresses
Jan 29 06:56:04 astoria dnsmasq[1344]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Jan 29 06:56:04 astoria dnsmasq-dhcp[1344]: read /var/lib/libvirt/dnsmasq/default.hostsfile
It never gets to `DHCPDISCOVER`, `DHCPOFFER` etc, so I don't see these records. The output from `iptables -nL` is identical.
I'll try replacing my version of NetworkManager with something else.
Offline
Arrowhead
Member
Registered: 2021-11-27
Posts: 7
OK, it's working now!
Toolybird wrote:
Total speculation, but my top suspects would be systemd and/or networkmanager.
You were exactly right.
My problem was that I had both `NetworkManager` and `systemd-networkd` enabled and running at the same time. How this happened I have no idea, but I blame the GUI installer. Once I disabled `systemd-networkd`, the problem disappeared.
Thanks!
Offline
wildbb
Member
Registered: 2022-01-27
Posts: 5
For those who choose systemd-networkd (I have several setup files in /etc/systemd/network/ to rename interfaces and all so I had a kind of incentive on my side).
First thanks @Lone_Wolf, you lead me to the solution on my side (about primarily looking at the bridge setup). I also found this link which helped me understand some other points: Custom routed network
I didn't strictly applied the setup given in the link but from it I understand that starting the virtual network with virsh trigger systemd to start another instance of dnsmasq which is incompatible by default to the dnsmasq setup for my host as a router. So the solution on my side is:
From this moment everything worked fine be it a Windows or Linux image.
Hope it can help, if not sorry for the spam.
PS: part of the solution I found is based on my lack of understanding on how to setup correctly two dnsmasq instances (among other things I must admit). There might certainly be a simpler solution with systemd-networkd.
Offline
sdamaye
Member
Registered: 2016-05-19
Posts: 6
I was struggling with the same issue as you guys (DHCP not assigning IP addresses to my VM while virbr0 interface was up) and eventually fixed my issue by appending
firewall_backend = "iptables"
to
/etc/libvirt/network.conf
, as recommended in the doc (https://wiki.archlinux.org/title/Libvirt#Server). Hopefully this will be helpful.
Offline
fivetech
Member
Registered: 2025-03-06
Posts: 1
sdamaye wrote:
I was struggling with the same issue as you guys (DHCP not assigning IP addresses to my VM while virbr0 interface was up) and eventually fixed my issue by appending
firewall_backend = "iptables"to
/etc/libvirt/network.conf, as recommended in the doc (https://wiki.archlinux.org/title/Libvirt#Server). Hopefully this will be helpful.
I was also struggling with this issue, with VMs didn't get IP by DHCP server inside QEMU. When /etc/libvirt/network.conf was with default configuration with nftables, my VMs was not getting IP by DHCP (and all nftables packets was installed as well the service running ). But when I decided switch nftables to iptables on host hypervisor (running Arch Linux!!) and changed the configuration in /etc/libvirt/network.conf to use iptables
firewall_backend = "iptables"
, the VMs finally started to get IP by DHCP.
Last edited by fivetech (2025-03-06 14:16:46)
Offline
zman58
Member
Registered: 2025-04-10
Posts: 1
Earlier this week I setup an Arch Linux virt server using the latest download. I ran into an issue with the "default" network not working. I believe that installing the package "dnsmasq" resolved the issue. All is good now, see below:
# For some reason, we were unable to start the network "default" in virt-manager????
# Install the dnsmasq package and deps
sudo pacman -S dnsmasq
# Set the "default" network to autostart
sudo virsh net-autostart default
# Start the default network
sudo virsh net-start default
sudo virsh net-list --all
Name State Autostart Persistent
--------------------------------------------
default active yes yes
Offline
k3.jignesh
Member
Registered: 2025-07-25
Posts: 1
If someone is still facing issues after trying out above solutions, below solution did worked for me. I am running Arch on QEMU virt manager on Fedora 42 host.
On host:
> sudo iptables -t nat -L -n
You should see rules for MASQUERADE on virbr0.
If not, enable IP forwarding:
> sudo sysctl -w net.ipv4.ip_forward=1
And reload firewalld if using it:
> sudo firewall-cmd --zone=libvirt --add-interface=virbr0
> sudo firewall-cmd --reload
Try Restarting VM + libvirt
> sudo systemctl restart libvirtd
Then reboot the VM.
This will actually start packet forwarding from virtual NAT (where VM is connected) to internet via host machine. Without this, packets will arrive till host but they won't be routed to real network interface.
Offline