On 09/05/2013 12:47 PM, Chris Friesen wrote: Both. Any case where a crash has transitioned the domain into a shutoff state (no qemu process exists any more), in such a way that libvirt knows that it is a crash. Depending on what version of kernel you have and what version of qemu you are using, you can set things up so that qemu exposes '-device pvpanic' to the guest, and Linux guests can then write to that device on kernel panic, so that qemu then forwards a crash event to libvirt. (Theoretically, someone could write a windows driver so that Windows guests could also trigger the qemu event, but to date, no one has done that). With that in place, a guest panic would no longer show up as running(booted), but as crashed(panicked). But right now, since qemu 1.6 botched the implementation of '-device pvpanic', we are waiting for qemu 1.7 to stabilize the design, so there is no easy way to pass -device pvpanic on the qemu command line except using <qemu:commandline> XML extensions that take you into the realm of unsupportedness. To differentiate between the qemu panic event (the qemu process still exists) and the completely dead qemu (your kill -9 attempt), if you are using the pvpanic device. Trust me, this whole area is a big mess, that has been drawn out in several long debates on both qemu and libvirt lists, for more than a year now. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org