> 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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1163147

Title:
  Please run dnsmasq in such a way that it can also be used on the host
  — to look up the VMs' names

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1163147/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to