Re: [libvirt] Crash state and QEMU

On Tue, May 10, 2011 at 14:28:20 -0500, Anthony Liguori wrote: > On 05/10/2011 02:04 PM, Richard W.M. Jones wrote: > > On Tue, May 10, 2011 at 01:26:39PM -0500, Anthony Liguori wrote: > >> As far as I can tell, if QEMU exits abruptly or with a non-zero > >> status code, libvirt treats this as a domain destruction given no > >> real indication to the user that something bad happened. > > > > libvirtd raises an event. > > But that event is no different than the event fired for a normal guest > shutdown, no? It is different, after normal shutdown libvirt issues (VIR_DOMAIN_EVENT_STOPPED, VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN) event while crashed qemu results in (VIR_DOMAIN_EVENT_STOPPED, VIR_DOMAIN_EVENT_STOPPED_FAILED) event. Moreover, once "Introduce virDomainGetState API" patch set makes it into libvirt, there will be a way to detect crashed domain offline without listening to events, e.g.: # virsh domstate --reason $DOM shut off (crashed) However, shut off reason is not maintained across libvirtd restarts so after restarting libvirtd the reason will be unknown. > >> But libvirt does have a crashed state for domains, it's just not > >> used for QEMU guests. > > > > I'll just make a historical note that the crashed state corresponded > > to a state in Xen. Essentially the states in libvirt are directly > > mapped to the ones listed in the Xen xm man page here: > > > > http://linux.die.net/man/1/xm > > I'm well aware of that :-) > > That's why I asked whether not using the crash state was intentional (if > it's deprecated as a general API). IIRC, the crashed state as used in Xen is similar to zombie processes. That is, crashed domain still exists in the system and one needs to get rid of it using virsh destroy when it's no longer needed. We don't have anything like that for qemu, if it crashes, it just disappears so the state is shown as shutoff.