[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
@Seth: Unless you prefer to drop the matter entirely, I'd suggest you edit the bug description to say exactly what it is that you want, as you know see it. This isn't very clear in the original posting, and after re-reading many of the comments above I don't feel I have a completely clear picture of what you would like. Once you've done that, then even if we don't take any action to implement I'd say we should keep this report open at importance Wishlist. Second, I think that with limited effort we can provide at least *part* of the desired functionality. I am happy to help with that. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
** Changed in: libvirt (Ubuntu) Status: Incomplete = Confirmed -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Hmm, well I don't think that this bug report is incomplete. We know what the problem is. What is unfinished is the implementation of the solution. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Sorry I haven't made much progress on this myself; I just don't install lxc on the system where I use libvirt. It's not a pleasing solution but it's mostly worked. I think part of the problem is that what I want is .. not what DNS software authors are expecting. I want a local DNS service that knows to query multiple authoritative servers and recursive resolvers simultaneously and somehow determine which of the responses should be given back to clients. It's not a usual problem to have. (Someone else may run mixed lxc and libvirt and expect all guests to be able to resolve all other guests, but they might just run their own dns infrastructure and eschew the built-in offerings, to avoid this specific issue.) I suspect what I want does not exist and would likely take significant engineering resources to make it work. Thanks -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
@Seth, any updates? ** Changed in: libvirt (Ubuntu) Status: New = Incomplete -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
This might be something to discuss on #ubuntu-devel. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Seth, the ball is in your court, I think. Try both approaches and see how well either or both of them works. I have favored the daisy-chain approach for the reasons given in comment #27 and because I can easily see how to support that approach using resolvconf such that it just works(tm) when packages are installed. If the routing-by-domain-name approach is preferred then we will have to figure out a j.w. solution for that. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
On Thu, Aug 8, 2013 at 7:26 PM, Seth Arnold 1163...@bugs.launchpad.net wrote: 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. Yes, it's a characteristic of the daisy chain approach that query-upstream nameservers can consult query-downstream ones but not vice versa. 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. It's the intent that this be automated using resolvconf. That takes care of the case where an instance of dnsmasq is stopped correctly. It doesn't take care of the case where a dnsmasq instance crashes or is stopped improperly. If a query-downstream dnsmasq instance crashes then upstream instances won't be able to resolve any downstream names. 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.) I don't understand you here. Can you elaborate? So, instead of a chain, how about a flatter layout? [...] 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. The glibc resolver is not a good place to route queries to different nameservers. The glibc resolver can only consult one nameserver at a time. It queries the first nameserver in the list, waits five seconds, then queries the next nameserver in the list if it hasn't received a reply. Queries to the second nameserver are delayed by TIMEOUT every single time. Queries to the third nameserver are delayed by TIMEOUT * 2. There can be no fourth nameserver. That is not acceptable. And shortening the timeout is no solution. Don't abuse dnsmasq as a forwarder, because it doesn't handle it as smoothly as it could. Dnsmasq works very well as a forwarder. And unlike the glibc resolver, dnsmasq can route queries by domain suffix without introducing delays, e.g., it can be configured to consult nameserver A for *.lbvrt and nameserver B for *.lxc. The glibc resolver appears to handle multiple nameservers all configured as 'nameserver' lines in /etc/resolv.conf even if they serve up different data. dnsmasq does not appear to handle this case well (I think this is what you called NNN in bug 1003842), and thus we should probably try to avoid using dnsmasq in this way. Dnsmasq handles this case either as well as, or better than, the glibc resolver. If various nameservers are available, each containing different data, then either (1) dnsmasq can be run in strict-order mode, in which case it works in the same way as the glibc resolver in the relevant respect, or (2) dnsmasq can be told to route queries to nameservers by domain suffix, in which case it works much better than the glibc resolver because it processes the queries without delay. Bug #1003842 does not necessarily detract from dnsmasq's usefulness in this case. Bug #1003842 is simply the fact that when dnsmasq is not running in strict-order mode and is given multiple nameservers to forward to (for a given domain) then it assumes that they are equivalent whereas on some networks the nameservers are not equivalent. [...] We may need to increase MAXNS in /usr/include/resolv.h and rebuild nearly everything. So I guess there are downsides. :) Yep, unfortunately MAXNS is not configurable at run time. If the glibc resolver doesn't actually handle multiple nameservers with different data in them well, then probably Someone needs to write a DNS resolver that can handle this well. Bug #1003842 would probably also benefit from a dns resolver that forwards to all configured DNS servers and tries to give the best of all available responses. (This could eliminate the rebuild everything step, so it might be worthwhile anyway.) I don't want to repeat the bug #1003842 discussion here. So, what do you think? Is there an argument to be made for a flat approach that does not use the dnsmasq instances as forwarders? Or is the better approach still the chaining approach, and hooking together libvirt, lxc, and the various VPN servers in one long chain? The daisy chain approach will work and so will the routing-by-domain- name approach that Serge has proposed and which
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
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. The glibc resolver appears to handle multiple nameservers all configured as 'nameserver' lines in /etc/resolv.conf even if they serve up different data. dnsmasq does not appear to handle this case well (I think this is what you called NNN in bug 1003842), and thus we should probably try to avoid using dnsmasq in this way. If it were instead authoritative-only for the dhcp-registered hosts, I have a feeling we could construct a simpler answer. We may need to increase MAXNS in /usr/include/resolv.h and rebuild nearly everything. So I guess there are downsides. :) If the glibc resolver doesn't actually handle multiple nameservers with different data in them well, then probably Someone needs to write a DNS resolver that can handle this well. Bug #1003842 would probably also benefit from a dns resolver that forwards to all configured DNS servers and tries to give the best of all available responses. (This could eliminate the rebuild everything step, so it might be worthwhile anyway.) So, what do you think? Is there an argument to be made for a flat approach that does not use the dnsmasq instances as forwarders? Or is the better approach still the chaining approach, and hooking together libvirt, lxc, and the various VPN servers in one long chain? Thanks -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
So the situation is more complex than we thought. No problem, though: we should be able to handle any number of dnsmasq instances in daisy chain. Do you think you understand the various components well enough to hand- craft a solution on your machine? If so then the next step is to escort the needed changes into the various packages involved, as we have discussed earlier. If you doubt that you can get it working on your own then I'd be happy to work with you on the solution. Send me e-mail (gmail username jdthood) so we can communicate with each other directly. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
So really isn't this just a result of bug 1003842? -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Hi Seth, So based on some reading for related bugs, I found the following to work! 1. I added server=/lxc/10.0.3.1 server=/libvirt/192.168.122.1 to /etc/dnsmasq.conf 2. I added -s lxc to the dnsmasq command in /etc/init/lxc-net.conf 3. restarted both of the dnsmasqs Now I was able to resolve r0.lxc correctly from 10.0.3.1! -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
I don't know what you mean by 'this', so I can't answer your question directly. What I can say is that bug #1003842 implies that where you have dnsmasq-A, dnsmasq-B, dnsmasq-C which you want to operate in daisy chain, A forwarding to B and B to C, and you want to give C's listen address to A as a second forwarding address (so that A can contact C if B crashes) then you have to run A in strict-order mode. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
All my previous advice was given without knowing that you needed a distinct dnsmasq instance for LXC. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Thomas, thanks for the advice: I took the fix from 3.2 and 4 and the advice to rename my update.d script to /etc/resolvconf/update.d/dnsmasq- libvirt What works: On the host, Internet host name lookups On the host, LAN host name lookups In KVM guests, Internet host name lookups In KVM guests, other KVM guest name lookups What doesn't work: On the host, KVM guest name lookups In KVM guests, LAN name lookups Now that your fix from 3.2 is in place, I can see that the situation is rather more complicated than I expected: Once I fixed the dnsmasq command line, it now starts, and I have two dnsmasq servers for virtual environments, one for LXC and one for libvirt. I modified the command line arguments for the LXC-aimed dnsmasq. The libvirt dnsmasq uses a configuration file, /var/lib/libvirt/dnsmasq/default.conf ##WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE ##OVERWRITTEN AND LOST. Changes to this configuration should be made using: ##virsh net-edit default ## or other application using the libvirt API. ## ## dnsmasq conf file created by libvirt strict-order domain-needed user=libvirt-dnsmasq local=// pid-file=/var/run/libvirt/network/default.pid except-interface=lo bind-dynamic interface=virbr0 dhcp-range=192.168.122.2,192.168.122.254 dhcp-no-override dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases dhcp-lease-max=253 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts I haven't yet tried the simplification of getting rid of 127.0.3.1. I have a feeling that I need to further configure the libvirt-owned dnsmasq instance before getting too fancy. (For the same reason, I've also held off the managed upstart for the lxc-owned dnsmasq.) I'm now too sleepy to see the modifications that might be needed. I thought I should document all this progress before I sleep, though. Thanks Thomas and Serge! -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Oh yes, I also have a feeling that I'll need a second update.d/ file -- I'm using the name dnsmasq-libvirt for the one I have now, but I think that the one I have now is actually being used by the LXC-owned dnsmasq. There's a lot of mentions of libvirt in the /etc/init/lxc-net.conf that now feel incorrect -- they're starting a dnsmasq for LXC use. libvirt starts its own dnsmasq somewhere else, and these names should probably be applied to it instead. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
I tried adding --server 192.168.122.1 to the lxc-net.conf dnsmasq server, in the hopes that it would forward queries for my VM guests to the libvirt dnsmasq server, but that broke everything: VM guests, LAN hosts, and Internet hosts. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Hi Serge, I agree that it's still debatable what the default behavior should be. There are at least two behaviors which would be sane. 1. VMs have the same view of DNS as their host except that they can resolve names of VMs. 2. VMs have the same view of DNS as their host including being able to resolve names of VMs. AIUI, #1 is the current default behavior. The submitter seems to claim that #2 used to be the default behavior; in any case the submitter requests that #2 be the default behavior in the future. Behavior #2 is obviously more convenient. Implementing it requires that the host send DNS queries to dnsmasq-libvirt. That may not be what maintainers are willing to configure as the default, but it's something that I think should at least be offered as an option. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Just a note to say that 1. IIUC there is not yet a conclusion about a workable and proper fix (frankly I'm not yet convinced that the original behavior as used by sarnold was not the sanest) 2. I think at this point the bug should still be marked as affecting both dnsmasq and libvirt ** Changed in: libvirt (Ubuntu) Importance: Undecided = Medium -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
1. Note that my instructions in comment #12 are partly superseded by my comments in #16. I think you understood that. To make it clear for other readers I will repeat the instructions below. 2. In comment #16 I wrote Also you will have to do echo nameserver 127.0.3.1 | resolvconf -a lo.dnsmasq-libvirt and resolvconf -d lo.dnsmasq-libvirt without saying *when* these commands need to be run. You understood what I meant, but to make it clear for others: one has to do echo nameserver 127.0.3.1 | resolvconf -a lo.dnsmasq-libvirt after dnsmasq-libvirt has started and resolvconf -d lo.dnsmasq-libvirt before stopping it. 3. Your etc-init-lxc-net.conf starts dnsmasq with incorrect options. You need to be careful with how bind-interfaces, interface and listen-address options are used. You do the following --bind-interfaces --listen-address=10.0.3.1 --interface=lxcbr0 --interface=127.0.3.1 3.1. You presumably meant the following. --bind-interfaces --listen-address=10.0.3.1 --interface=lxcbr0 --listen-address=127.0.3.1 The argument of --interface= must be the name of an interface, not an IP address; the --interface=127.0.3.1 will cause dnsmasq to fail to start. On my machine, dnsmasq 2.65-1ubuntu1 with --interface=127.0.3.1 prints unknown interface 127.0.3.1. 3.2. In bind-interfaces mode dnsmasq binds all and only the addresses on interfaces that it is configured to listen on. By default it listens on all interfaces that are present when it starts, but when you give an interface option, dnsmasq listens only that interface plus interface lo. You can add listen addresses by giving additional interface and listen-address options. So if you give --listen-address=10.0.3.1 --interface=lxcbr0 --listen-address=127.0.3.1 then dnsmasq will listen on 10.0.3.1, 127.0.3.1, 127.0.0.1 plus the address of lxcbr0. What you want is for it to listen on the virtual-machine-facing address(es) and on 127.0.3.1 but not on 127.0.0.1. Assuming that the virtual-machine-facing addresses are 10.0.3.1 and the address of lxcbr0, the options should be: --bind-interfaces --listen-address=10.0.3.1 --interface=lxcbr0 --except-interface=lo --listen-address=127.0.3.1 3.3. (We would be better off using bind-dynamic than bind-interfaces so that dnsmasq-libvirt continues to listen on the correct addresses when interfaces go up and down and have their addresses changed. However, my testing seems to indicate that you can't use bind-dynamic along with listen-address. That's a bug, I think, which I will report, but until it's fixed we can't use bind-interfaces along with listen- address, alas.) 4. Now create the script /etc/resolvconf/update.d/dnsmasq-libvirt (not .../dnsmasq which will conflict with the script installed by the dnsmasq package). The script you posted (etc-resolvconf-update.d-resolvconf) is good for that except that one line has to be changed. The line RSLVCNFFILES=$(/lib/resolvconf/list-records | sed -e '/^lo.dnsmasq$/d') must be RSLVCNFFILES=$(/lib/resolvconf/list-records | sed -e '/^lo.dnsmasq- libvirt$/d') to reflect the fact that we are going to use the record name dnsmasq- libvirt. To be ready for resolvconf 1.74 it should be RSLVCNFFILES=$(/lib/resolvconf/list-records --after lo.dnsmasq- libvirt | sed -e '/^lo.dnsmasq-libvirt$/d') so please use this. 5. Currently the Upstart job file starts dnsmasq in the pre-start script. You should actually use an exec clause to start dnsmasq so that Upstart can monitor it. This means that you need to create a separate dnsmasq-libvirt job file with triggers that look something like the following. start on starting lxc-net stop on stopping lxc-net The Upstart Cookbook http://upstart.ubuntu.com/cookbook recommends that the daemon be execed in foreground mode. So instead of running dnsmasq in a pre-start script, add an exec stanza. exec dnsmasq --keep-in-foreground ...other...options... Then put the following echo nameserver 127.0.3.1 | resolvconf -a lo.dnsmasq-libvirt in a post-start script stanza and resolvconf -d lo.dnsmasq-libvirt in a pre-stop script stanza. Warning: I haven't tested this. 6. After all this is done, when lxc is started it should start dnsmasq- libvirt which registers one of its listen addresses 127.0.3.1 with resolvconf which calls its update scripts which writes the addresses of external nameservers to /var/run/dnsmasq-libvirt/resolv.conf and writes 127.0.3.1 to /etc/resolv.conf so that resolving on the host goes through dnsmasq-libvirt and dnsmasq-libvirt forwards queries that it can't answer itself to the external nameservers. 7. To simplify things we could omit 127.0.3.1 and just register one of the virtual-machine-facing addresses with resolvconf. Edit the Upstart job file to start dnsmasq with --bind-interfaces --listen-address=10.0.3.1 --interface=lxcbr0 --except-interface=lo and in the post-start do echo nameserver 10.0.3.1 | resolvconf -a
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Thomas, sorry for the slow response, I had a family issue come up. I believe I followed the directions in comment #12 and when I rebooted, I found myself without any working DNS at all -- no Internet hosts, no LAN hosts, no VM guests. I didn't troubleshoot too far because of your additional advice in comment #16 -- which, again, I think I followed, and also does not work. I could not resolve Internet hosts, LAN hosts. (I must admit I haven't yet tried VM guests.) root@hunt:~# netstat -nlp | grep :53 tcp0 0 192.168.122.1:530.0.0.0:* LISTEN 1966/dnsmasq udp0 0 0.0.0.0:53530.0.0.0:* 1388/avahi-daemon: udp0 0 192.168.122.1:530.0.0.0:* 1966/dnsmasq udp6 0 0 :::5353 :::* 1388/avahi-daemon: root@hunt:~# ps auxw | grep dnsmasq 118 1966 0.0 0.0 26080 996 ?S18:45 0:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf root@hunt:~# getent passwd 118 libvirt-dnsmasq:x:118:127:Libvirt Dnsmasq,,,:/var/lib/libvirt/dnsmasq:/bin/false I don't understand at all where this dnsmasq is being started from, because the --conf-file in the /etc/init/lxc-net is left blank. There are no other instances of 'dnsmasq' in /etc/init/* or /etc/init.d/*. I've attached the files I recall modifying. ** Attachment added: etc-dhcp-dhclient.conf https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1163147/+attachment/3743242/+files/etc-dhcp-dhclient.conf -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
** Attachment added: etc-init-lxc-net.conf https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1163147/+attachment/3743243/+files/etc-init-lxc-net.conf -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
** Attachment added: etc-resolvconf-update.d-resolvconf https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1163147/+attachment/3743245/+files/etc-resolvconf-update.d-resolvconf -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
** Attachment added: etc-NetworkManager-NetworkManager.conf https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1163147/+attachment/3743244/+files/etc-NetworkManager-NetworkManager.conf -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Resolvconf 1.74 will include a new feature which will make it easy to adapt dnsmasq server (as requested by me in Debian bug report #716908) to work properly in the situation where it is in the middle of a chain: dnsmasq-libvirt - dnsmasq server - dnsmasq-NM. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
I wrote in comment #16: 3. Consider now case #1 where you add dnsmasq-server (from the dnsmasq package) into the mix. Dnsmasq-server forwards to dnsmasq-NM — this already works. Dnsmasq-libvirt should forward to dnsmasq-server. If you have set things up as decribed above then this should happen. On second thought I realize that there is a small problem. If dnsmasq server is installed on a system as in case #1 then dnsmasq server will forward to dnsmasq-libvirt, thus creating a loop. In order to prevent this from happening, dnsmasq-server's resolvconf hook script has to be modified to exclude the record lo.dnsmasq-libvirt (just as it already excludes its own record lo.dnsmasq). Once libvirt is enhanced as we are proposing here (bug #1163147), I will see to it that the necessary change is made to dnsmasq: I think that the change should be made via an enhancement to resolvconf that I already had in mind but I won't go into detail here about that. -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
I believe the 192.168.122.1 comes first due to the /etc/dhcp/dhclient.conf configuration Doh — yes, of course. I overlooked the following bit. Put a line into /etc/dhcp/dhclient.conf like so: prepend domain-name-servers 192.168.122.1; Disable the system dnsmasq to prevent it from looping with libvirt's dnsmasq by modifying /etc/NetworkManager/NetworkManager.conf to comment out the following line: #dns=dnsmasq Note that in connection with my comment #12 you should remove the prepend domain-name-servers 192.168.122.1; from dhclient.conf. The resolvconf -a command takes its place. If things are set up properly then it won't be necessary to comment out dns=dnsmasq in NetworkManager.conf. Everything should work either with dns=dnsmasq or without dns=dnsmasq. For clarity I will describe both cases in detail. Note that in what follows I have replaced the string dnsmasq (which I used in comment #12) with dnsmasq-libvirt, this in order to avoid conflicting with the dnsmasq package; this with an eye to inclusion of this feature in libvirt and, in so doing, avoiding conflict with the dnsmasq package. :) Because of this change you will also have to add a line to /etc/resolvconf/interface-order: just above lo.dnsmasq add a line lo.dnsmasq-libvirt. Also you will have to do echo nameserver 127.0.3.1 | resolvconf -a lo.dnsmasq-libvirt and resolvconf -d lo.dnsmasq-libvirt Why have I used the address 127.0.3.1 here? Because dnsmasq listens at 127.0.0.1; dnsmasq-NM listens at 127.0.1.1; and dnscrypt-proxy listens at 127.0.2.1. Also you will have to create a directory /var/run/dnsmasq-libvirt/ and modify the hook script to write /var/run/dnsmasq-libvirt/resolv.conf instead of /var/run/dnsmasq/resolv.conf. OK. Assume that your ISP has a nameserver NI which resolves Internet names. Assume your router's nameserver NR resolves your LAN names and forwards queries for other names to NI. Assume machines on your LAN have a resolv.conf containing nameserver addrR where addrR is the address of the router. 1. Consider the case where you have dns=dnsmasq in NetworkManager.conf on your laptop which runs NetworkManager (NM). Assume NM gets the laptop's IP address and nameserver address addrR via DHCP from the DHCP server running on the router. NM starts a local dnsmasq instance (dnsmasq-NM) and passes addrR to dnsmasq-NM. dnsmasq-NM then listens locally at 127.0.1.1 and forwards all queries to addrR. NM adds a record called NetworkManager to resolvconf's database containing nameserver 127.0.1.1. Now you start libvirt. Libvirt starts a dnsmasq instance, dnsmasq- libvirt, and adds a record called lo.dnsmasq-libvirt to resolvconf's database by means of the command 'echo nameserver 127.0.3.1 | resolvconf -a lo.dnsmasq-libvirt'. When the database is updated the resolvconf update hook scripts are run. dnsmasq-libvirt has such a hook script which reads in the database records in the order determined by /etc/resolvconf/interface-order, excludes the one called 'lo.dnsmasq- libvirt' and generates /var/run/dnsmasq-libvirt/resolv.conf containing nameserver 127.0.1.1. When the latter file changes, the dnsmasq- libvirt process notices this and reads the file and is thereby configured to forward queries that it can't itself answer to 127.0.1.1. Another resolvconf update hook script called 'libc' generates a new resolv.conf file containing nameserver 127.0.3.1. Resolver clients on the laptop thus query dnsmasq-libvirt which queries dnsmasq-NM which queries NR which queries NI. 2. Consider now the case where you have #dns=dnsmasq. NM gets the laptop's IP address and addrR via DHCP. NM adds a record called NetworkManager to resolvconf's database containing nameserver addrR. Now you start libvirt. Libvirt starts dnsmasq-libvirt and adds a record called lo.dnsmasq-libvirt to resolvconf's database. When the database is updated, dnsmasq-libvirt's resolvconf-update hook script is run and generates /var/run/dnsmasq-libvirt/resolv.conf containing nameserver addrR. dnsmasq-libvirt is thus configured to forward queries to addrR. The libc hook script generates resolv.conf containing nameserver 127.0.3.1. Resolver clients on the laptop thus query dnsmasq-libvirt which queries NR which queries NI. 3. Consider now case #1 where you add dnsmasq-server (from the dnsmasq package) into the mix. Dnsmasq-server forwards to dnsmasq-NM — this already works. Dnsmasq-libvirt should forward to dnsmasq-server. If you have set things up as decribed above then this should happen. I've made some changes to my /etc/init/lxc-net script, stolen the dnsmasq package's resolvconf hook script -- I'll test it shortly. Thanks! Cool! Once this is working it should be considered for incorporation into libvirt. -- 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 —
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
Having re-read your original description I have a couple of questions for you. 1. How did it come to pass that nameserver 192.168.122.1 is first in your resolv.conf, as given in the description? Does libvirt add that line, or did you customize something? 2. You say that you can resolve the VM FQDNs ending in .local. Does this go via mDNS or via dnsmasq? -- 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
[Bug 1163147] Re: Please run dnsmasq in such a way that it can also be used on the host — to look up the VMs' names
I believe the 192.168.122.1 comes first due to the /etc/dhcp/dhclient.conf configuration: prepend domain-name-servers 192.168.122.1; It might also have come first as a result of my previous debugging efforts. (Sorry. :) I think the .local VM FQDN lookups are using mDNS -- at least, wireshark showed a fair amount of mDNS traffic but no DNS traffic when I just now tested. I've made some changes to my /etc/init/lxc-net script, stolen the dnsmasq package's resolvconf hook script -- I'll test it shortly. Thanks! -- 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
