Bug 740577 - /var/lib/libvirt/dnsmasq/default.hostsfile lags behind changes
/var/lib/libvirt/dnsmasq/default.hostsfile lags behind changes
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
14
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Laine Stump
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-22 10:32 EDT by Laine Stump
Modified: 2012-01-25 08:10 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 713728
Environment:
Last Closed: 2012-01-24 16:47:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Laine Stump 2011-09-22 10:32:56 EDT
+++ This bug was initially created as a clone of Bug #713728 +++

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?

--- Additional comment from nphilipp@redhat.com on 2011-08-03 09:13:50 EDT ---

Ping?

--- Additional comment from crobinso@redhat.com on 2011-08-03 10:23:30 EDT ---

Laine, any thoughts?

--- Additional comment from laine@redhat.com on 2011-08-03 16:34:58 EDT ---

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 1 Fedora Admin XMLRPC Client 2011-09-22 13:59:34 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 2 Fedora Admin XMLRPC Client 2011-09-22 14:03:17 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 3 Fedora Admin XMLRPC Client 2011-11-30 14:59:26 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Fedora Admin XMLRPC Client 2011-11-30 15:00:23 EST
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-11-30 15:05:41 EST
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 15:05:52 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Cole Robinson 2012-01-24 16:47:31 EST
F14 is EOL, so closing this.
Comment 8 Laine Stump 2012-01-25 08:10:40 EST
And as indicated above, it was fixed upstream, so is in later releases of Fedora (starting with F16)

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