Bug 740577 - /var/lib/libvirt/dnsmasq/default.hostsfile lags behind changes
Summary: /var/lib/libvirt/dnsmasq/default.hostsfile lags behind changes
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 14
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Laine Stump
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-22 14:32 UTC by Laine Stump
Modified: 2012-01-25 13:10 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 713728
Environment:
Last Closed: 2012-01-24 21:47:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Laine Stump 2011-09-22 14:32:56 UTC
+++ 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 on 2011-08-03 09:13:50 EDT ---

Ping?

--- Additional comment from crobinso on 2011-08-03 10:23:30 EDT ---

Laine, any thoughts?

--- Additional comment from laine 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 17:59:34 UTC
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 18:03:17 UTC
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 19:59:26 UTC
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 20:00:23 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-11-30 20:05:41 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:05:52 UTC
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 21:47:31 UTC
F14 is EOL, so closing this.

Comment 8 Laine Stump 2012-01-25 13:10:40 UTC
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.