Bug 277671 - libvirt starts dnsmasq inappropriately, preventing DNS queries from working
Summary: libvirt starts dnsmasq inappropriately, preventing DNS queries from working
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 7
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-05 01:56 UTC by Russell Robinson
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-09-05 14:52:35 UTC
Type: ---
Embargoed:


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

Description Russell Robinson 2007-09-05 01:56:45 UTC
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-05 01:56:45 UTC
Created attachment 186791 [details]
Shell script to workaround the problem

Comment 2 Daniel Veillard 2007-09-05 07:48:45 UTC
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 09:21:09 UTC
Created attachment 187181 [details]
Virtual Machine XML

Comment 4 Russell Robinson 2007-09-05 09:21:33 UTC
Created attachment 187191 [details]
Network XML

Comment 5 Russell Robinson 2007-09-05 09:23:57 UTC
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 Berrangé 2007-09-05 14:48:16 UTC
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 Berrangé 2007-09-05 14:52:35 UTC
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 12:20:26 UTC
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.