Bug 816185

Summary:	Doesn't start dnsmasq for bridged network if system-wide dnsmasq is running
Product:	[Fedora] Fedora	Reporter:	Nils Philippsen <nphilipp>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	berrange, clalancette, crobinso, dougsland, itamar, jforbes, jyang, laine, libvirt-maint, nphilipp, veillard, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-04-26 14:39:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	752653

Description Nils Philippsen 2012-04-25 13:06:59 UTC

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.

Comment 1 Nils Philippsen 2012-04-25 13:11:27 UTC

NB: this is not bug #734903

Comment 2 Daniel Berrangé 2012-04-25 13:20:50 UTC

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

Comment 3 Nils Philippsen 2012-04-26 11:18:15 UTC

(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.

Comment 4 Nils Philippsen 2012-04-26 14:39:09 UTC

With the updates installed, both dnsmasq processes come up well after booting.