[libvirt] Bug - libvirt persists on having dnsmasq

[Laine Stump]

On 08/16/2011 02:00 PM, Matthias Bolte wrote:
> 2011/8/16 Zdenek Styblik<stybla at turnovfree.net>:
>> On 08/16/11 18:07, Zdenek Styblik wrote:
>> [...]
>>>>> Well, libvirt.spec has had Require: dnsmasq for at least a couple
>>>>> years, so any install of a libvirt rpm should fail when dnsmasq
>>>>> isn't present. I don't know for certain how long the BuildRequires:
>>>>> dnsmasq has been there, but certainly for at least a year (the last
>>>>> time the line was modified), so any rpm builds should also fail.
>>>>>
>>>>> But of course if you're running ./autogen.sh and then make, that
>>>>> doesn't involve the specfile.
>>>>>
>>>>> dnsmasq really is an integral part of the network driver; I don't
>>>>> know that it makes any sense to "fix" things so it can be built
>>>>> without dnsmasq. It's probably a good idea to make the failure
>>>>> complete though.
>>>> We already have an option to disable the virtual network driver. I don't
>>>> think we want to have a separate option for dnsmasq, since that is an
>>>> integral part of hte network driver IMHO
>>>>
>>>> Daniel
>>> I'm sorry, but what? I did not understand single word, and I mean it -
>>> no irony, no pun.
>>>
>>> In other words and what I took from the reply, you mean to tell me from
>>> libvirt-0.9.4 and on one is forced to have dnsmasq around resp. to use
>>> libvirt?
>>>
>>> Thanks,
>>> Z.
>>
>> So, let me just repeat whole thing again.
>>
>> Up until libvirt version 0.9.3, libvirt was able to auto-magically
>> detect presence of dnsmasq. And in case dnsmasq was not found during
>> ./configure; libvirt wouldn't try to use it.
> Actually I think that's not true. I think the code just accidentally
> ignored it when dnsmasq could not be started. This commit (part of
> libvirt 0.9.4)
>
> http://libvirt.org/git/?p=libvirt.git;a=commit;h=85a954cebbbb3ae6210a779a5f3b29559ec5f862
>
> fixed this. I didn't test it but this seems to be the cause for the
> problem you're describing.
>
>> However, since libvirt version 0.9.4 resp. in libvirt version 0.9.4 this
>> auto-magical detection does not work and libvirt persists on using
>> dnsmasq which is not present.
> True, because a bug was fixed. It may look to you as there was a
> feature that's broken now, but that's not the case, I think. The code
> is expecting dnsmasq to be available when a virtual network is used.
>
> A simple solution for you might be to revert commit
> 85a954cebbbb3ae6210a779a5f3b29559ec5f862 and go back to exploiting the
> bug, that made it work for you as you expect it.
>
>> I don't know what to make from your replies as it seems like you don't
>> want to get blame for this one nor there seems to be will not to make
>> libvirt dnsmasq independent.
> I don't think that this is the case here. I think Dan and Laine
> weren't aware that there was a bug fixed in libvirt 0.9.4 that gave
> you the impression that dnsmasq was optional.

Correct, since I always build on machines that have dnsmasq installed, 
and the specfile requires it, I was unaware that a build could be done 
without dnsmasq, and definitely would have considered it a bug if I'd 
known that was the case.


>> I blame nobody. I want to know, I want to fix it one way or another, and
>> move on.
> One could argue that the virtual network code could be more fine
> grained and only start dnsmasq when it's really necessary, as this is
> what you expect from it. Currently it tries to start dnsmasq when the
> network contains an<ip>  element. See
>
> http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/network/bridge_driver.c#l1806
>
> You might suggest that it only should start/require dnsmasq when there
> is a<dhcp>  element or something DNS related that really makes dnsmasq
> necessary.

I think this was discussed awhile back, and stated that we want a DNS 
server "whenever possible" even if DHCP isn't needed, which translates 
into "when an <ip> is defined for the network".


If having dnsmasq installed is too heavyweight, you can always construct 
your own bridge outside of libvirt, and use type='bridge' for your 
interfaces rather than type='network'.

(We might want to revisit all of this, since the virtual networks are 
now used for more than just the "linux bridge+dhcp+dns+iptables" setup.)