Bug 687291

Summary: dnsmasq not started for networks with no dhcp range and no static hosts
Product: Red Hat Enterprise Linux 6 Reporter: Laine Stump <laine>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1CC: dallan, dyuan, eblake, mjenner, xhu
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-0.8.7-13.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 13:29:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Laine Stump 2011-03-15 14:57:23 UTC
The patches to add IPv6 support to libvirt virtual networks (Bug 586124) inadvertently introduced a regression in behavior: when a virtual network has no dhcp range or static hosts defined, dnsmasq should still be run, in order to provide DNS services to the guests on the network; after IPv6 support was added, a network with neither dhcp range nor static hosts did *not* get an instance of dnsmasq.

This behavior has already been fixed upstream:

commit 7892edc9cc45e4fb1079b627bda3f571ac27041f
Author: Laine Stump <laine>
Date:   Fri Mar 11 11:47:58 2011 -0500

    network driver: Start dnsmasq even if no dhcp ranges/hosts are specified.
    
    This fixes a regression introduced in commit ad48df, and reported on
    the libvirt-users list:
    
      https://www.redhat.com/archives/libvirt-users/2011-March/msg00018.html
    
    The problem in that commit was that we began searching a list of ip
    address definitions (rather than just having one) to look for a dhcp
    range or static host; when we didn't find any, our pointer (ipdef) was
    left at NULL, and when ipdef was NULL, we returned without starting up
    dnsmasq.
    
    Previously dnsmasq was started even without any dhcp ranges or static
    entries, because it's still useful for DNS services.
    
    Another problem I noticed while investigating was that, if there are
    IPv6 addresses, but no IPv4 addresses of any kind, we would jump out
    at an ever higher level in the call chain.
    
    This patch does the following:
    
    1) networkBuildDnsmasqArgv() = all uses of ipdef are protected from
       NULL dereference. (this patch doesn't change indentation, to make
       review easier. The next patch will change just the
       indentation). ipdef is intended to point to the first IPv4 address
       with DHCP info (or the first IPv4 address if none of them have any
       dhcp info).
    
    2) networkStartDhcpDaemon() = if the loop looking for an ipdef with
       DHCP info comes up empty, we then grab the first IPv4 def from the
       list. Also, instead of returning if there are no IPv4 defs, we just
       return if there are no IP defs at all (either v4 or v6). This way a
       network that is IPv6-only will still get dnsmasq listening for DNS
       queries.
    
    3) in networkStartNetworkDaemon() - we will startup dhcp not just if there
       are any IPv4 addresses, but also if there are any IPv6 addresses.

commit e368e71040de75f4021784f792d96e6674029f45
Author: Laine Stump <laine>
Date:   Fri Mar 11 12:07:09 2011 -0500

    network driver: Fix indentation from previous commit
    
    The previous commit put a large portion of networkBuildDnsmasqArgv
    inside an if { } block. This readjusts the indentation.

Comment 3 Laine Stump 2011-03-15 15:44:38 UTC
A rebase of the upstream patch has been sent to rhvirt-patches for consideration:

  http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-March/msg00332.html
  http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-March/msg00334.html

Comment 4 Laine Stump 2011-03-15 17:17:35 UTC
v1 of the patch series was missing a prerequisite. New posting to rhvirt-patches: 

http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-March/msg00343.html
http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-March/msg00342.html

Comment 11 errata-xmlrpc 2011-05-19 13:29:01 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html