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.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list