Description of problem: I have a system-wide dnsmasq service running on my machine which binds to localhost and localhost6. Libvirtd then doesn't start dnsmasq for its bridged (default) network, therefore guests don't get DHCP leases. Version-Release number of selected component (if applicable): libvirt-0.9.11-1.fc17.x86_64 libvirt-daemon-0.9.11-1.fc17.x86_64 dnsmasq-2.59-5.fc17.x86_64 How reproducible: Reproducible. Steps to Reproduce: 0. On a system with dnsmasq configured to bind to loopback addresses 127.0.0.1 and ::1, and libvirtd having a default bridged network, and both set up to be started at boot time from systemd: 1. Boot the system 2. "pgrep -lf dnsmasq" Actual results: 6236 /usr/sbin/dnsmasq -s gibraltar Expected results: 6236 /usr/sbin/dnsmasq -s gibraltar 5930 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile Additional info: Stopping both libvirtd and dnsmasq services, then starting libvirtd again, then dnsmasq works as expected. I can only guess that libvirtd thinks the system-wide dnsmasq process is responsible for the bridged network as well (which it isn't). This setup worked in Fedora 16.
NB: this is not bug #734903
libvirt does not do any apriori checks for a global dnsmasq process - it will unconditionally launch its dnsmasq when starting the default network Your global dnsmasq process needs to be explicitly configured to play nicely with libvirt. By default it will immediately try to bind to all interfaces on the system, which then causes libvirt's dnsmasq to quit Your dnsmasq args posted above don't include the suitable config args, and I'm guessing your config file doesn't either http://wiki.libvirt.org/page/Libvirtd_and_dnsmasq NB, nothing has changed in the way libvirt deals with dnsmasq between F16 and F17 - the same rules should apply
(In reply to comment #2) > libvirt does not do any apriori checks for a global dnsmasq process - it will > unconditionally launch its dnsmasq when starting the default network > > Your global dnsmasq process needs to be explicitly configured to play nicely > with libvirt. By default it will immediately try to bind to all interfaces on > the system, which then causes libvirt's dnsmasq to quit > > Your dnsmasq args posted above don't include the suitable config args, and I'm > guessing your config file doesn't either You're guess is off ;-): --- 8< --- /etc/dnsmasq.d/local_config --- [...] interface=lo bind-interfaces --- >8 ----------------------------------- I've also checked this with lsof on dnsmasq processes and none of them bound to 0.0.0.0, only to 127.0.0.1/::1 ("my" dnsmasq process) and 192.168.122.1 (libvirt's). That's why I mentioned that this isn't bug #734903 :-P. > NB, nothing has changed in the way libvirt deals with dnsmasq between F16 and > F17 - the same rules should apply This is odd. I have run "strace -Ff -e execve /usr/sbin/libvirtd" and it seemed as if it didn't even attempt to start dnsmasq. I've just applied a bunch of updates and will reboot the system to observe behavior starting from a "clean slate". NB: I'm on vacation from tomorrow on and will be back on May 10th.
With the updates installed, both dnsmasq processes come up well after booting.