Re: [Qemu-devel] [PATCH 0/2] Introduce panic hypercall

[Avi Kivity <avi@redhat.com>]

On 06/20/2011 06:38 PM, Daniel P. Berrange wrote:
> On Mon, Jun 20, 2011 at 06:31:23PM +0300, Avi Kivity wrote:
> >  On 06/20/2011 04:38 PM, Daniel Gollub wrote:
> >  >Introduce panic hypercall to enable the crashing guest to notify the
> >  >host. This enables the host to run some actions as soon a guest
> >  >crashed (kernel panic).
> >  >
> >  >This patch series introduces the panic hypercall at the host end.
> >  >As well as the hypercall for KVM paravirtuliazed Linux guests, by
> >  >registering the hypercall to the panic_notifier_list.
> >  >
> >  >The basic idea is to create KVM crashdump automatically as soon the
> >  >guest paniced and power-cycle the VM (e.g. libvirt<on_crash />).
> >
> >  This would be more easily done via a "panic device" (I/O port or
> >  memory-mapped address) that the guest hits.  It would be intercepted
> >  by qemu without any new code in kvm.\
> >
> >  However, I'm not sure I see the gain.  Most enterprisey guests
> >  already contain in-guest crash dumpers which provide more
> >  information than a qemu memory dump could, since they know exact
> >  load addresses etc. and are integrated with crash analysis tools.
> >  What do you have in mind?
>
> Well libvirt can capture a "core" file by doing 'virsh dump $GUESTNAME'.
> This actually uses the QEMU monitor migration command to capture the
> entire of QEMU memory. The 'crash' command line tool actually knows
> how to analyse this data format as it would a normal kernel crashdump.

Interesting.

> I think having a way for a guest OS to notify the host that is has
> crashed would be useful. libvirt could automatically do a crash
> dump of the QEMU memory, or at least pause the guest CPUs and notify
> the management app of the crash, which can then decide what todo.
> You can also use tools like 'virt-dmesg' which uses libvirt to peek
> into guest memory to extract the most recent kernel dmesg logs (even
> if the guest OS itself is crashed&  didn't manage to send them out
> via netconsole or something else).

I agree.  But let's do this via a device, this way kvm need not be changed.

Do ILO cards / IPMI support something like this?  We could follow their 
lead in that case.

> This series does need to introduce a QMP event notification upon
> crash, so that the crash notification can be propagated to mgmt
> layers above QEMU.

Yes.

-- 
error compiling committee.c: too many arguments to function