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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list