On Wed, 15 Feb 2012 11:00:25 +0000
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Wed, Feb 15, 2012 at 02:44:18PM +0800, Wen Congyang wrote:
> Hi all:
>
> If the guest runs on xen, we can know the guest OS paniced, and the guest status
> is paniced. But if the guest runs on qemu/kvm, we need the same feature. And the
> feature to know guest-is-panic is a very very good feature for enterprise.
>
> We have some ways to know that guest has paniced:
> 1. watchdog timeouts
> It is not a good way, because we can not say "the guest is paniced" in
100% accuracy
> 2. use a PV driver(like the XEN)
> The old RHELs do not have such driver...
> It can not work for the second kernel...
> 3. Adding a function for console-logging (in ring buffer or some) and check
messages
> given by guests. If we allow some filtering script or some, we can catch
Linux's
> panic messages. We can say the guest paniced if we catch such messages. We may
be
> able to catch other events by other script
>
> I prefer to 3 now. Does anyone have a better idea?
I have discussed this with Anthony before and the thought was that QEMU/KVM
should provide some kind of paravirtualized crash notification service to
the guest. ie option 2. such a device would likely be quite simple and
thus possible to backport to older kernels as needed
AFAIK, linux kernel has notifier at panic but it doesn't work if kdump is
enabled.
And IIRC, There was a discussion in lkml that any modules should not be called when
crash_kexec() is called. So, no chance to notify it from the module in the 1st kernel,
now.
Calling it from 2nd kernel will work but the bahavior will be different from
non-kdump guest.
Can't we do notify by hypercall ? But this will require guest modification..
Thanks,
-Kame