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!
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. Daniel
Created attachment 187181 [details] Virtual Machine XML
Created attachment 187191 [details] Network XML
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
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.
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.
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.