[libvirt] Proposal: no dnsmasq (no dhcp and no dns) and no radvd option

[Gene Czarcinski]

On 11/21/2012 07:31 AM, Daniel P. Berrange wrote:
> On Wed, Nov 21, 2012 at 07:18:20AM -0500, Gene Czarcinski wrote:
>> On 11/20/2012 05:29 PM, Laine Stump wrote:
>>> On 11/20/2012 02:36 PM, Gene Czarcinski wrote:
>>>> Laine mentioned something yesterday that got me to thinking: being
>>>> able to specify that dnsmasq is not to be started for an interface.
>>>>
>>>> Let me expand that by saying that libvirt would not start dnsmasq for
>>>> either dns or dhcp and also would not start radvd.  However, the IPv4
>>>> and IPv6 gateway addresses would be defined on the virtual network
>>>> interface and the "usual" iptables and ip6tables rules would be in force.
>>>>
>>>> This would allow a user to configure dnsmasq to meet any user desires
>>>> or use something completely different instead of dnsmasq.
>>>>
>>>> Questions:  Useful?  Worth the time and effort?
>>> That was already determined before I mentioned it to you - it's been
>>> requested several times, and I've told some people it was "going to
>>> happen", although didn't say when :-).
>>>
>>>>    And then there is how should this be specified in the network xml
>>>> file? ... some new parameter?  ... A subperameter of <dns> such as
>>>> <dns disable='yes' /> ?  ... a subparameter of <bridge> such as
>>>> <bridge name="virbr0" dns="disable" /> ?
>>> The <bridge> element is commonly *not* specified manually, but is filled
>>> in automatically be libvirt, so I don't think it's a good place to put
>>> optional flags (you would end up manually specifying settings for the
>>> things that are automatically filled in, like the bridge name).
>>>
>>> If anything, I would say the choice would be between putting it in <dns>
>>> or in the toplevel <network>, i.e.:
>>>
>>>      <network>
>>>      ...
>>>        <dns disable='yes'/> (or maybe "<dns enable='no'/> is better)
>>>      ...
>>>      </network>
>>>
>>> or
>>>
>>>      <network dns='no'>
>>>        ...
>>>      </network>
>>>
>>> Or, maybe it would be even better to put it in the <ip> element:
>>>
>>>      <ip address='192.168.122.1' netmask='255.255.255.0' dns='no'/>
>>>
>>> that way you could have dnsmasq listen on some of the IP addresses
>>> defined for a network, but not others.
>>>
>>> At the same time, we probably to be able to disable ipv6 RA as well.
>>> Since that's only enabled when there is an ipv6 address, it can also be
>>> added into the <ip> element config:
>>>
>>>      <ip family='ipv6' address='f00d::1' ra='no'/> (or maybe
>>> "autoconf='no'" ?)
>>>
>>> Yeah, I think I like it best in <ip> (unless someone else has a better
>>> idea).
>> Not really better since I like the idea of adding this to <ip>.
>> However, I believe this is wrong!  it is a mistake to tie this to an
>> IP address.  Look at the problems that have occurred with dnsmasq.
> I agree, we should let this be controlled independently of
> the <ip> tag. You might want to allow DNS, without defining
> any IP elements at all.
Mmmm.  The only way this could work is if --interface=<virbrnn> was 
specified.  Right now, if no IPv4 or IPv6 addresses are specified, this 
this is not a virtual gateway device but a virtual network interface for 
very isolated guest-to-guest only communications.  [see patch I just 
submitted to make IPv6 have the same functionality as IPv4].
>
>> Instead, I suggest that this be an expansion to <network>.
>>   For example, <network dns='no'>.  This could also scratch
>> an itch of mine for specifying logging:
>>   <network dnslog='yes" dhcplog='yes'>.  Then there is the
>> issue with bind-intererface and bind-dynamic:
>>   <network bind='dynamic'>
> Since you envisage multiple config parameters related to
> DNS, this argues for a top level <dns> element to group
> them all together.
>
>    <network>
>      ...
>      <dns.../>
>      ...
>    </network>
Yes, dns currently has two possible items: dns=yes/no and dnslog=noyes.  
But dhcplog=no/yes and bind=interface/dynamic are not really related to 
dns.  I suggest just keeping it simple and at a single level under 
<network>.  I hope I am making my point understandable because I am not 
sure of the terminology used for discussing xml.

Gene