Bug 277671 - libvirt starts dnsmasq inappropriately, preventing DNS queries from working
libvirt starts dnsmasq inappropriately, preventing DNS queries from working
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
7
All Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-04 21:56 EDT by Russell Robinson
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-05 10:52:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Shell script to workaround the problem (1.45 KB, text/plain)
2007-09-04 21:56 EDT, Russell Robinson
no flags Details
Virtual Machine XML (1.04 KB, text/xml)
2007-09-05 05:21 EDT, Russell Robinson
no flags Details
Network XML (309 bytes, text/xml)
2007-09-05 05:21 EDT, Russell Robinson
no flags Details

  None (edit)
Description Russell Robinson 2007-09-04 21:56:45 EDT
Description of problem:
dnsmasq is supposed to answer DNS queries related to the machines for which it
has assigned DHCP addresses.

However, the fixed options that libvirt uses to start dnsmasq prevent these
queries from happening.

So, one ends up with virtual machines with unknowable IP addresses.

Version-Release number of selected component (if applicable):
dnsmasq-2.38-1.fc7
libvirt-0.3.2-1.fc7

How reproducible:
Always.  dnsmasq is never set to listen for DNS queries on anything other than
the private interface for the virtual machines.

Steps to Reproduce:
1. Start a virtual machine
2. On another machine, try to query the host name: "host blahblah" or "host
blahblah.domainname"
  
Actual results:
Host not found.

Expected results:
Host IP address returned.

Additional info:
I've written a shell script that removes the offending parameters to dnsmasq and
adds some extra ones.

Works perfectly now!
Comment 1 Russell Robinson 2007-09-04 21:56:45 EDT
Created attachment 186791 [details]
Shell script to workaround the problem
Comment 2 Daniel Veillard 2007-09-05 03:48:45 EDT
Hum, that's strange ... Can you provide the output of the 
'virsh dumpxml' command for the domain as well as the 
'net-dumpxml' dump for the network you may have defined.

Daniel
Comment 3 Russell Robinson 2007-09-05 05:21:09 EDT
Created attachment 187181 [details]
Virtual Machine XML
Comment 4 Russell Robinson 2007-09-05 05:21:33 EDT
Created attachment 187191 [details]
Network XML
Comment 5 Russell Robinson 2007-09-05 05:23:57 EDT
I've attached the files.

Note that these XML files are exactly what Fedora Virtual Machine Manager
creates, except I adjusted the <clock > tag for localtime and manually added the
cdrom.

regards,
Russell
Comment 6 Daniel Berrange 2007-09-05 10:48:16 EDT
Removing the "--bind-interfaces" and "--listen-address" flags is completely
bogus because it prevents multiple copies of dnsmasq running at the same time,
which is a central requirement to be able to serve different IP address ranges
to different virtual networks.
Comment 7 Daniel Berrange 2007-09-05 10:52:35 EDT
Further to 

> dnsmasq is never set to listen for DNS queries on anything other than
> the private interface for the virtual machines.

This is explicitly the correct & desired behaviour. dnsmasq is *only* supposed
to be offering DNS to virtual machines on the particular virtual network it is
associated with. It is absolutely *not* supposed to answer queries from other
physical hosts. Note that the IP addresses given out are from the private
address pool 192.168.122.0/24, and this same range is used on all machines - the
guests at NAT'd to the outside world.
Comment 8 Russell Robinson 2007-09-06 08:20:26 EDT
Hi,

That's a fair enough explanation and I accept that.

However, how does one make a VM accessible on a LAN?

The case I have would not be unusual:
1. Host machine is on a LAN.
2. Guest machines are things like Windows.  The VM's are merely replacements for
what would otherwise be physical machines.
3. These Windows VM's need to be known on the LAN so that other machines can
talk to them.

Locking them behind a NAT process isn't always the way one want's things done.


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