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.