Bug 713728

Summary: /var/lib/libvirt/dnsmasq/default.hostsfile lags behind changes
Product: [Fedora] Fedora Reporter: Nils Philippsen <nphilipp>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: berrange, clalance, crobinso, eblake, itamar, jforbes, laine, 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:
: 727982 729207 740577 (view as bug list) Environment:
Last Closed: 2012-06-07 00:59:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nils Philippsen 2011-06-16 11:46:07 UTC
Description of problem:
When editing a network in virsh ('net-edit default', 'net-destroy/start default') to e.g. add a new MAC/IP static address combo, /var/lib/libvirt/dnsmasq/default.hostsfile seems to lag one "version" behind, i.e. carries combos only from the previous edit. To make the current ones effective, changing an unrelated one (e.g. change a hex digit from upper to lowercase) then destroying/restarting the network helps (the unrelated change is only effective on the next change though).

I haven't found this issue in RH/Fedora Bugzilla, but googling gave me an open ticket on Launchpad for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/584910

Version-Release number of selected component (if applicable):
libvirt-0.8.8-4.fc15.x86_64
libvirt-client-0.8.8-4.fc15.x86_64
libvirt-python-0.8.8-4.fc15.x86_64

How reproducible:
Reproducible

Steps to Reproduce:
1. 'net-edit default', then add a new static DHCP mapping to the default network (e.g. <host mac='FF:FF:EE:EE:DD:DD' ip='192.168.122.254' />)
2. 'net-destroy default'
3. 'net-start default'
4. 'grep FF:FF:EE:EE:DD:DD /var/lib/libvirt/dnsmasq/default.hostsfile'
  
Actual results:
(nothing)

Expected results:
FF:FF:EE:EE:DD:DD,192.168.122.254


BTW, I noticed that destroying/starting the network makes it unusable on running guests without rebooting them (they don't ping, restarting the network service in the guest or equivalent doesn't help). Is that expected/intentional or are there ways to add a new static MAC/IP address combo without having to reboot other running guests?

Comment 1 Nils Philippsen 2011-08-03 13:13:50 UTC
Ping?

Comment 2 Cole Robinson 2011-08-03 14:23:30 UTC
Laine, any thoughts?

Comment 3 Laine Stump 2011-08-03 20:34:58 UTC
The problem is that when an active network is re-defined, the new data is stored in network->newDef, but the code that builds the new hosts files uses network->def (the old version of the config). If the network is inactive at the time it's redefined, then the new data is stored directly into network->def, and it takes effect immediately.

I just posted a patch upstream to fix the problem:

https://www.redhat.com/archives/libvir-list/2011-August/msg00181.html

Comment 4 Fedora Admin XMLRPC Client 2011-09-22 17:55:04 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Fedora Admin XMLRPC Client 2011-09-22 17:58:32 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Fedora Admin XMLRPC Client 2011-11-30 20:06:24 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Fedora Admin XMLRPC Client 2011-11-30 20:06:27 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 8 Fedora Admin XMLRPC Client 2011-11-30 20:09:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 9 Fedora Admin XMLRPC Client 2011-11-30 20:09:59 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Eric Blake 2011-12-01 18:13:14 UTC
We should backport this into F15 the next time we do a build.

commit 3aa84653d1c457b1c12efd4b8449e31525042254
Author: Laine Stump <laine>
Date:   Wed Aug 3 15:33:24 2011 -0400

    network: eliminate lag in updating dnsmasq hosts files
    
    This addresses https://bugzilla.redhat.com/show_bug.cgi?id=713728
    
    When "defining" a new network (or one that exists but isn't currently
    active) the new definition is stored in network->def, but for a
    network that already exists and is active, the new definition is
    stored in network->newDef, and then moved over to network->def as soon
    as the network is destroyed.

Comment 11 Cole Robinson 2012-06-07 00:59:25 UTC
Given that F15 is EOL in a matter of weeks, I'm closing this WONTFIX. This should already be fixed in F16+, but if someone is still seeing issues, please reopen.