Quoting Seth Arnold (<email address hidden>):
> Thomas, the more I've read about dnsmasq and the complaints from other
> users in bug 1003842, the more I think that we might be better off taking
> a different approach entirely. Please let me know what you think.
>
> Your dnsmasq-A, dnsmasq-B, dnsmasq-C daisy-chain approach could probably
> work. But guest VMs or guest LXC domains that are using dnsmasq-B couldn't
> then look up hosts registered with dnsmasq-C.
>
> This daisy chain would be brittle: if dnsmasq-B is stopped by the
> administrator or otherwise dies, dnsmasq-C's configuration would need
> to be updated to forward to dnsmasq-A instead.
>
> And, libvirt-controlled guests and lxc-controlled guests would also
> need networking properly configured to route between libvirt guests and
> lxc guests. This might not be desirable. (In that case, you wouldn't
> care that they couldn't look up hostname information from the other
> virtualization technology anyway.)
>
> So, instead of a chain, how about a flatter layout?
>
> I haven't yet wrapped my head around the entirety of the implementation.
> But I wanted to share what I'd thought of so far to get your feeling if
> this is even useful to pursue to the end.
>
> Have dnsmasq-lxc, dnsmasq-libvirt, authoritative for their own little
> networks. If an lxc guest wants to resolve libvirt guests, the lxc guest
> needs to have /etc/resolv.conf configured to query both dnsmasq-lxc
> and dnsmasq-libvirt. If a libvirt guest wants to resolve lxc guests,
> the libvirt guest needs to have /etc/resolv.conf configured to query
> both dnsmasq-libvirt and dnsmasq-lxc.
>
> If those guests also want to resolve LAN hosts or Internet hosts, they'll
> need to add more "nameserver" lines. Don't abuse dnsmasq as a forwarder,
> because it doesn't handle it as smoothly as it could.
I guess the reason this confused me when I first read it last week is
because I *thought* this was how we expected things to work before,
and what your original request was for. But I think I see the
distinction now.
Quoting Seth Arnold (<email address hidden>):
> Thomas, the more I've read about dnsmasq and the complaints from other
> users in bug 1003842, the more I think that we might be better off taking
> a different approach entirely. Please let me know what you think.
>
> Your dnsmasq-A, dnsmasq-B, dnsmasq-C daisy-chain approach could probably
> work. But guest VMs or guest LXC domains that are using dnsmasq-B couldn't
> then look up hosts registered with dnsmasq-C.
>
> This daisy chain would be brittle: if dnsmasq-B is stopped by the
> administrator or otherwise dies, dnsmasq-C's configuration would need
> to be updated to forward to dnsmasq-A instead.
>
> And, libvirt-controlled guests and lxc-controlled guests would also
> need networking properly configured to route between libvirt guests and
> lxc guests. This might not be desirable. (In that case, you wouldn't
> care that they couldn't look up hostname information from the other
> virtualization technology anyway.)
>
> So, instead of a chain, how about a flatter layout?
>
> I haven't yet wrapped my head around the entirety of the implementation.
> But I wanted to share what I'd thought of so far to get your feeling if
> this is even useful to pursue to the end.
>
> Have dnsmasq-lxc, dnsmasq-libvirt, authoritative for their own little
> networks. If an lxc guest wants to resolve libvirt guests, the lxc guest
> needs to have /etc/resolv.conf configured to query both dnsmasq-lxc
> and dnsmasq-libvirt. If a libvirt guest wants to resolve lxc guests,
> the libvirt guest needs to have /etc/resolv.conf configured to query
> both dnsmasq-libvirt and dnsmasq-lxc.
>
> If those guests also want to resolve LAN hosts or Internet hosts, they'll
> need to add more "nameserver" lines. Don't abuse dnsmasq as a forwarder,
> because it doesn't handle it as smoothly as it could.
I guess the reason this confused me when I first read it last week is
because I *thought* this was how we expected things to work before,
and what your original request was for. But I think I see the
distinction now.