On Fri, Mar 09, 2007 at 02:02:55PM +0000, Richard W.M. Jones wrote:
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.
Yes, that could be a very useful way to detect guest shutdown without needing to maintain the PPID<->PID relationship & waitpid(). Definitely something to experiment with in the near future. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|