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

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.

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.

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).