© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
> I don't think it used to be the default behavior, rather it was
> trivial to make it the behavior by adding 192.168.122.1
I think you are right. I misspoke.
>> in any case the submitter requests that #2 be the default
>> behavior in the future.
>
> I don't think (as one of the libvirt packaging maintainers) I'd want
> it to be the default behavior, but trivially configurable to do so.
Agreed.
And I think I put the wrong words in the submitter's mouth. Re-reading what he originally wrote I think he wants what you just suggested: that it be *easy to activate* behavior #2 (i.e., that VMs and host are both able to resolve names of VMs and of "upstream" DNS names).
But this isn't the main issue, of course. The main issue is that the submitter couldn't obtain behavior #2 at all.
> It seems like there should be a simple config command to tell the
> host dnsmasq that *.libvirt goes to 192.168.122.1 (and then ignore
> such requests from 192.168.122.1), *.lxc goes to 10.0.3.1, etc.
Actually that is possible with dnsmasq, and what you suggest here is an alternative approach to the one I have been proposing.
What I have been proposing is that the host resolver consult dnsmasq-libvirt which forwards to upstream DNS. The VM resolvers do exactly the same. That way both the host resolver and the VM resolvers can resolve both VM names and upstream names.
The alternative approach you suggest is, IIUC, for the host resolver to consult a host dnsmasq instance ("dnsmasq server") which forwards queries regarding VM names to dnsmasq-libvirt and forwards queries regarding other names to the upstream nameserver.
The alternative approach has several drawbacks, in my opinion. First, it only works if the host runs dnsmasq (i.e., an instance distinct from dnsmasq-libvirt). Second, it absolutely requires that VM names have their own TLD(s). Third, if the user wants to resolve short VM names then the search path has to be set correctly in resolv.conf. Fourth, support for dynamic configuration (e.g., the right thing is done when dnsmasq-libvirt is stopped or started) requires either that libvirt reconfigure dnsmasq server or that resolvconf be enhanced to do this tidily (see Debian bug report #710960). Finally, it means that the host and the VMs achieve exactly the same ends by different means. This approach thus seems more complex and error-prone than the one I was proposing. But perhaps it also has advantages.