I recently updated libvirt* on my test system and found out something interesting. Although libvirtd is restarted , the dnsmasq instantiations it has are not restarted. In fact, if you remove virtualization from the system, the dnsmasq instantiations are still running. In fact, you have to manually kill them or reboot the system to remove them. If you are updated libvirt*, then you can do a "virsh net-destroy <whatever>" AND THEN A "virsh net-start <whatever>" OK, is this a bug (which I will report) or simply a "feature" that I do not like?

On 09/10/2012 10:17 AM, Gene Czarcinski wrote: > I recently updated libvirt* on my test system and found out something > interesting. Although libvirtd is restarted , the dnsmasq > instantiations it has are not restarted. > > In fact, if you remove virtualization from the system, the dnsmasq > instantiations are still running. > > In fact, you have to manually kill them or reboot the system to remove > them. > > If you are updated libvirt*, then you can do a > "virsh net-destroy <whatever>" > AND THEN A > "virsh net-start <whatever>" > > > OK, is this a bug (which I will report) or simply a "feature" that I do > not like? Remember that libvirtd must leave the network up even when libvirtd goes down, so that it does not interfere with any running guest; bouncing dnsmasq might be guest-visible, so it has to be commanded by more than just a libvirtd restart. I seem to recall that there is a known bug where libvirtd blindly assumes that dnsmasq is already running, rather than ensuring it is started back up if necessary, but that doesn't quite seem to be what your are asking. Meanwhile, your net-destroy/net-start way of bouncing the network to force it to pick up the new config for dnsmasq is the correct way to restart the network, as restarting libvirtd alone must not do that role.