[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] A Big OOPS!!



On 10/24/2012 07:23 AM, Gene Czarcinski wrote:
A big OOPS!!!

On 10/23/2012 04:55 PM, Gene Czarcinski wrote:
On 10/23/2012 04:10 PM, Laine Stump wrote:
I wouldn't worry about that quite yet. Let's wait until it's pushed
upstream. At the point, we'll probably want the first two (for F17 and
F18, which have dnsmasq-2.63 which according to you causes problems).
Not me, Simon Kelley the dnsmasq developer/maintainer/etc.

Rather than just pasting his comment here, got to look at the message he wrote:

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q4/006415.html

There might be a way to make it work with just the gateway address (that is what listen-address really is because dnsmasq does not really need an address just the interface), but that is not how it was done.
After I sent the message, I just got something in from Simon Kelley which has some new info: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q4/006445.html

The heart of it is this:
--------------------------------------------------
OK, so this is vaguely embarrassing. Having checked the actual code,
rather than the changelog, I see that dnsmasq >=2.61 _already_ does the
right thing. Setting --bind-interfaces* and a single --listen-address
will cause the code to set SO_BINDTODEVICE on the DHCP socket(s).

So, there is not a problem with the existing libvirt command line.
I disagree.  I believe that the problem still exists.

What Simon says implies that everything is OK and nothing needs to be done but consider this:

1. What harm does it do to add the interface=<> specification in addition to everything else?

2. Note that Simon states "Setting --bind-interfaces* and a single --listen-address ". Well, I can define multiple IPv4 and/or IPv6 listen-addresses to be on a single virtual interface. From what Simon says, that means all bets are off.

3. I suspect that many/most instances of dnsmasq only has a single address and that is why the problem has not manifested itself.

4.  I do not know if a v4 and v6 address counts as one or two.

And one more round on this ...
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2012q4/006447.html
--------------------------------------------
OK, learning from past mistakes and checking the code, this is what happens.

You can have as many --listen-address as you like, as long as the
addresses all belong to the same interface. This applies to both IPv4
and IPv6,  so if you have an interface with two addresses

192.168.0.10 and
fd00::10

then

dnsmasq --listen-address=192.168.0.10 --listen-address=fd00::10

would set SO_BINDTODEVICE. But if those addresses belonged to two
different interfaces, the same command line would not set
SO_BINDTODEVICE. The same applies with more than one IPv4 or IPv6
address, so an interface with addresses

192.168.0.10 and
192.168.1.10

sets SO_BINDTODEVICE with

dnsmasq --listen-address=192.168.1.10 --listen-address=192.168.0.10

so it looks like libvirt is good.
--------------------------------------------------------

So, interface= is NOT necessary and everything is working just fine using only --listen-address=

I still believe that specifying interface= rather than the (possibly multiple) --list-address= is just plain cleaner but ... what now exists works.

The problem only occurs when you do something that libvirt's use of dnsmasq does not do ... have multiple dnsmasq instances each with multiple interfaces and only using --listen-address.

So ... put it in ... don't put it in ... your options.

Gene


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]