Bug 674356 - dnsmasq option --dhcp-lease-max prevents startup for more than 1 network
Summary: dnsmasq option --dhcp-lease-max prevents startup for more than 1 network
Keywords:
Status: CLOSED DUPLICATE of bug 663664
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-01 15:44 UTC by Brian J. Murrell
Modified: 2011-05-30 20:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-12 04:55:35 UTC
Embargoed:


Attachments (Terms of Use)
allocate a lease file per dnsmasq process (908 bytes, patch)
2011-02-01 16:32 UTC, Brian J. Murrell
no flags Details | Diff

Description Brian J. Murrell 2011-02-01 15:44:43 UTC
Description of problem:
If one configures more than one network to use DHCP, multiple dnsmasq processes are started, one for each network.  The problem is that each process has --dhcp-lease-max configured for the number of leases in it's own network.  But since multiple dnsmasq processes share the standard lease file it's possible that more leases are already in the lease file than the newly configured network yielding an error when the new dnsmasq tries to start:

dnsmasq: too many stored leases

Version-Release number of selected component (if applicable):
0.8.5

How reproducible:
100%

Steps to Reproduce:
1. define a /24 network in libvirt
2. obtain (or simulate by populating the leases file) 30 leases 
3. define a second /28 network
  
Actual results:
libvirtd will report:

09:46:47.004: error : virRunWithHook:857 : internal error '/usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/test.pid --conf-file=  --listen-address 10.0.1.1 --except-interface lo --dhcp-range 10.0.1.1,10.0.1.14 --dhcp-lease-max=14' exited with non-zero status 5 and signal 0: 
dnsmasq: too many stored leases

Expected results:
Should add the network and start the dnsmasq process without error.

Additional info:
Probably the "-l" option to dnsmasq would be useful here to create per network lease files.

Comment 1 Brian J. Murrell 2011-02-01 16:32:54 UTC
Created attachment 476445 [details]
allocate a lease file per dnsmasq process

This patch uses the --dhcp-leasefile option to give each dnsmasq it's own lease file.

Comment 2 Kenni Lund 2011-02-11 16:45:40 UTC
Duplicate of ticket #663664 - but that ticket doesn't contain a patch.

Comment 3 Laine Stump 2011-03-12 04:55:35 UTC
An updated patch to fix this has been committed upstream:

   commit 13c00dde3171b3a38d23cceb3f9151cb6cac3dad
   Author: Laine Stump <laine>
   Date:   Fri Mar 11 13:20:48 2011 -0500

   network driver: Use a separate dhcp leases file for each network

This will be in libvirt-0.9.0.

Comment 4 Laine Stump 2011-03-12 05:00:48 UTC

*** This bug has been marked as a duplicate of bug 663664 ***

Comment 5 Brian J. Murrell 2011-05-27 19:33:12 UTC
(In reply to comment #3)
> 
> This will be in libvirt-0.9.0.

It's really quite a pity that libvirt-0.9.0 didn't get cut in time for FC15 (or an 0.8.x.x bugfix release with this fix in it).  Since I have already fixed this bug on my Ubuntu 10.10 installation I'm afraid I'm not going to the effort to fix it again, on a brand new O/S release (FC15) and will just revert to my Ubuntu installation where this at least works.

In fact, without having done a terrible amount of debugging in FC15 (since I am abandoning it anyway), it would appear, at least, that multiple dnsmasq processes sharing a dnsmasq.leases file actually overwrite the file from under each other, rather than the previous behavior where they all (at least mostly) cooperatively shared the file and one just ran out of leases quickly.

Comment 6 Laine Stump 2011-05-30 20:53:06 UTC
(In reply to comment #5)
> 
> It's really quite a pity that libvirt-0.9.0 didn't get cut in time for FC15
> (or an 0.8.x.x bugfix release with this fix in it).

There is a new libvirt release once each month. There is also a cutoff date for rebasing packages for each new Fedora release. Whatever is the most recent release of libvirt on the cutoff date, that is the release that is put into Fedora for the release. In this case, libvirt-0.8.8 was the most recent on the F15 cutoff date.

virt-related packages like libvirt are not rebased for already-released versions of Fedora, but there are two methods of getting bugfixes:

1) request that a bugfix be pulled in as a patch to the release in use on that version of Fedora. When this happens, a patch release will be made (e.g., the version will go from 0.8.8-1 to 0.8.8-2). There is no automated method for bugfixes to go into libvirt of a released Fedora, an explicit request must be made.

2) use the fedora-virt-preview repo when doing "yum update". This will give you a build of the most recent upstream release of each of the packages. The F14 instructions on the wiki page will also work for F15 (as soon as the F15 version of the repo is online):

  http://fedoraproject.org/wiki/Virtualization_Preview_Repository

For a list of all the packages included in virt-preview, see: 

http://repos.fedorapeople.org/repos/jforbes/virt-preview/fedora-14/x86_64/

I am following up with jforbes to learn when the F15 incarnation of the virt-preview repo will be created.


Note You need to log in before you can comment on or make changes to this bug.