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

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

On Fri, Mar 09, 2007 at 10:47:18AM +0000, Richard W.M. Jones wrote: > 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. 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. > Maybe I'm missing something big here, but how would libvirt_qemud regain > connections to the running qemu monitor ptys? That's one of the challenges to be addressed :-) Fortunately the monitor is set to be exposed via /dev/pty/XXX, so if the restarted client can find out the path to the PTY, then it can re-open it. Maybe we just need to record a state file somewhere containing a PID & PTY path.

Richard W.M. Jones wrote: >Daniel P. Berrange wrote: >>On Fri, Mar 09, 2007 at 10:47:18AM +0000, Richard W.M. Jones wrote: >>>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. 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. >>>Maybe I'm missing something big here, but how would libvirt_qemud >>>regain connections to the running qemu monitor ptys? >> >>That's one of the challenges to be addressed :-) Fortunately the monitor >>is set to be exposed via /dev/pty/XXX, so if the restarted client can >>find out the path to the PTY, then it can re-open it. Maybe we just need >>to record a state file somewhere containing a PID & PTY path. > >Is it possible to start qemu with something like: > > qemu -monitor pipe:/var/some/known/place/pipe.UUID > >and then just look in /var/some/known/place/ in order to find the >running instances? I should add a note that you can tell if the qemu at the other end of the pipe has died by opening the pipe and writing something, for example a NO-OP command. If you get EPIPE (or SIGPIPE if you weren't careful to disable the signal) you can delete the pipe device.