Bug 277671

Summary: libvirt starts dnsmasq inappropriately, preventing DNS queries from working
Product: [Fedora] Fedora Reporter: Russell Robinson <russellr>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 7CC: xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-05 14:52:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Shell script to workaround the problem
none
Virtual Machine XML
none
Network XML none

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.