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

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.

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

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.