On Fri, 2007-03-09 at 03:25 +0000, Daniel P. Berrange wrote:
> Thinking about later RPM upgrades I think we need to think about whether it
> will be possible to restart the libvirt_qemud while guests & networks are
> running.
If I had time, I'd give some serious thought as to whether we need to
allow this. Are there any other examples of a daemon that manages
something long-lived that can't be restarted without shutting down what
it's managing?
> There's a couple of issues:
>
> - We do waitpid() to cleanup qemu & dnsmasq processes when we stop domains
> & networks, or to detect when they crash. For the former, we could may
> they daemons to avoid waitpid() cleanup, but we'd still need waitpid to
> be able to detect shutdowns. There is also the issue of enumerating
> running instances.
>
> - We always try to re-create a bridge device at startup, even if it already
> exists. Likewise we always try to add the IPtables rules & start dnsmasq.
> We can easily detect if the bridge already exists. I think we can probably
> double check iptables rulles too., The tricky one is figuring out whether
> a dnsmasq instance is still running.
>
> Dealing with theses not only helps planned restarts, but will also make it
> possible start up the daemon again after a crash without having to kill off
> all guests & networks manually. So I think it is worth investigating what
> we can do to enable restarts. It might be worth waiting until we sort out
> whether we'll merge libvirt_qemud with the generic libvirtd remote daemon
> though so we don't have to do the work twice over.
I guess the way I'd look at it is, a running qemud contains various
state - how do you recover that state on restart?
e.g.
- the list of running VMs, the PID of the qemu processes, the
stdout/stderr/monitor pipes, the domain ID, and the domain UUID if
we generated it
- the list of running networks, the bridge associated with each
network and the PID of the dnsmasq processes.
I could perhaps imagine using named pipes, caching this state in /var
and re-loading it on startup but ... non-trivial to say the least.
Cheers,
Mark.