Bug 727982 - /var/lib/libvirt/dnsmasq/default.hostsfile lags behind changes
/var/lib/libvirt/dnsmasq/default.hostsfile lags behind changes
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
: 729207 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2011-08-03 16:36 EDT by Laine Stump
Modified: 2011-12-06 06:20 EST (History)
15 users (show)

See Also:
Fixed In Version: libvirt-0.9.4-2.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 713728
Last Closed: 2011-12-06 06:20:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Laine Stump 2011-08-03 16:36:57 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):

How 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='' />)
2. 'net-destroy default'
3. 'net-start default'
4. 'grep FF:FF:EE:EE:DD:DD /var/lib/libvirt/dnsmasq/default.hostsfile'
Actual results:

Expected results:

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 ---


--- 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:

Comment 1 Daniel Veillard 2011-08-08 22:45:05 EDT
This was commited upstream:


Comment 2 Daniel Veillard 2011-08-08 22:45:28 EDT
This was commited upstream:


Comment 3 Daniel Veillard 2011-08-09 02:05:44 EDT
*** Bug 729207 has been marked as a duplicate of this bug. ***
Comment 10 errata-xmlrpc 2011-12-06 06:20:49 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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