On 09/05/2013 12:47 PM, Chris Friesen wrote:

Hi,

If I kill a libvirt-managed kvm process with "kill -9", running "virsh domstate --reason <name>" gives

shut off (crashed)

Looking at the code, that corresponds to VIR_DOMAIN_SHUTOFF/VIR_DOMAIN_SHUTOFF_CRASHED. The comment says that VIR_DOMAIN_SHUTOFF_CRASHED corresponds to "domain crashed". Is this supposed to be a crash of the hypervisor, or of the guest OS?

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.

If I trigger a panic in the guest, it sits there in the panicked state doing nothing and "virsh domstate" gives

running (booted)

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.

So what's the point of VIR_DOMAIN_CRASHED/VIR_DOMAIN_CRASHED_PANICKED?

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