Red Hat Bugzilla – Bug 277671
libvirt starts dnsmasq inappropriately, preventing DNS queries from working
Last modified: 2007-11-30 17:12:14 EST
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):
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
Host not found.
Host IP address returned.
I've written a shell script that removes the offending parameters to dnsmasq and
adds some extra ones.
Works perfectly now!
Created attachment 186791 [details]
Shell script to workaround the problem
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.
Created attachment 187181 [details]
Virtual Machine XML
Created attachment 187191 [details]
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
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.
> 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.
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.