@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
** 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
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
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
@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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
**
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
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
** 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.
** 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.
** 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
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
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
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
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
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
30 matches
Mail list logo
