[libvirt] [PATCH 1/2] v3: put dnsmasq parameters into a file instead of the command line

[Gene Czarcinski]

On 10/26/2012 10:36 AM, Laine Stump wrote:
> On 10/24/2012 04:27 PM, Gene Czarcinski wrote:
>> On 10/24/2012 01:31 PM, Laine Stump wrote:
>>>>> Is there some way (some command) that will cause dnsmasq to be
>>>>> restarted (possibly with new parameters as it re-does its
>>>>> configuration).  If this was done, then little, except some cached
>>>>> names, would be lost).  If there is not, maybe there should be.
>>>>> However, there are likely limits such as not changing the gateway
>>>>> addresses on the interface.
>>> I recently made a patch to check for a running dnsmasq anytime libvirt
>>> is restarted. If it's not running, it will be restarted. If it is
>>> running, a SIGHUP will be sent.
>>>
>>> Aside from that, the (newly created) accepted way to change a network's
>>> config while the network is up is to use the virNetworkUpdate API
>>> (available via virsh net-update). It permits you to add/delete/modify
>>> certain parts of the network config and have those changes take effect
>>> immediately if desired. the bridge_driver backend of virNetworkUpdate
>>> decides when it is necessary to either SIGHUP or restart dnsmasq
>>> according to what parts of the network definition have changed.
>>>
>>> A "live" change of the entire network definition (i.e. with
>>> virNetworkDefine() isn't supported, and won't be - anything that you
>>> want to be able to change while the network is up should be added to the
>>> "sections" modifiable by virNetworkUpdate. This will permit us to easily
>>> figure out what re-initialization is needed for a particular change
>>> without needing to just redo everything (for example, if a dhcp static
>>> host is added, we just need to SIGHUP dnsmasq, but if a dynamic range is
>>> added/deleted, we need to restart dnsmasq. If an IP address is
>>> added/removed from the bridge, we should be able to write code to simply
>>> redo the IP addresses on the existing bridge, rather than tear it down
>>> and build a new bridge (although that one isn't implemented yet).
>> Now this sounds like pretty much what I wanted.  It is OK to restart
>> dnsmasq but not OK to take the network down and then back up while a
>> virtual guest is using it.  Changing dhcp-range, hosts, or dhcp-host
>> should be no problem because the network interface remains.
>>
>> That said, there is something critical and that is the "gateway"
>> addresses.  Other software (not dsnmasq) needs to know these addresses
>> because they are really the interface between reality and the virtual
>> network.  That should not be able to be changed without taking down
>> the network.
> Depends. For the guests, all you need to do is set the linkstate down,
> then back up; for most OSes that causes the dhcp client to request a new
> lease. (really, we should probably do the same thing (at least
> optionally) when changing the range and the static hosts list, if we
> want to guarantee that all the guests are always obeying those settings.
>
>> Dnsmasq does not need the listen-address specifications if it is given
>> the drive name.  It will then listen on port 53 for all networks
>> defined on the interface.  For dhcp dnsmasq listens on 0.0.0.0:67/68
>> for v4 and :::547 for v6.  It then filers any incoming packet to make
>> sure that a dhcp-range has been specified for a subnet defined on that
>> interface.
> Is that 100% true? Awhile back someone filed a bug against libvirt
> saying that, because they had incorrectly specified the dynamic range to
> include the broadcast address of the subnet, they were getting a client
> that had been assigned the broadcast address as its IP.
The darn corner cases always cause problems.  This might even be a bug 
with dnsmasq ... it should at least gripe about any dhcp-range with 
includes the broadcast address.
>
>> I know it is supported [or at least it works] but I am a little fuzzy
>> about the usefulness of multiple IP addresses on the same interface
>> (other than IPv4 and IPv6).
> Well, I don't think it has much effect for dhcp (maybe it does when a
> client sends a unicast dhcp renew request (if I'm remembering dhcp
> correctly - it's been awhile since I looked at the details :-), but for
> DNS it will respond to DNS requests on any of those addresses.
If you specify the interface, yes dnsmasq should (and does) look at all 
of the subnetworks.  However, I do not know is that is true if you use 
listen-address.  I will try to remember to test that.
>
>
> Or are you talking about having multiple IPs in general? I guess it
> makes it possible for multiple subnets to share the same infrastructure
> (don't know how useful that is when the infrastructure is virtual :-).
> Anyway, if something works, someone will figure out a practical use for it.
It is possible to run more than one subnet on the same fabric ... real 
or virtual.  There might even be some real-world application where you 
want to separate a control network from the regular old (Internet 
accessible) network.  Of course, anyone who did not encrypt that second 
network odes not have all of their oars in the water ;)

And very real world application for running multiple networks on the 
same fabric (the same interface) is: dual stack IPv4 and IPv6.

Gene