[libvirt] Re: [PATCH] Hardware watchdog patch, version 6 (was: Re: [Qemu-devel] [PATCH] Hardware watchdog patch, version 5)
4:19 p.m.
Hi Rich, your watchdog qemu patch is working fine for me (i6300esb,
default reset behavior), but I was wondering... how should libvirt find
out about the watchdog firing?
At that point, I think the next step from libvirt is to send a
VIR_DOMAIN_EVENT_STOPPED_CRASHED domain event, correct?
--
Hollis Blanchard
IBM Linux Technology Center
3:39 a.m.
On Tue, Apr 07, 2009 at 04:19:42PM -0500, Hollis Blanchard wrote:
Hi Rich, your watchdog qemu patch is working fine for me (i6300esb,
default reset behavior),
Hi, first of all thanks for testing this. I'm going to put forward an
updated/finalized patch but it won't be til next week.
but I was wondering... how should libvirt find
out about the watchdog firing?
Good question. When we've talked about adding support for the
watchdog in libvirt, I've only been thinking about configuring it, not
about how to find out when it fires. This is a bit tricky because we
have to both get qemu to generate an event (eg. a monitor message),
and then get libvirt to handle that event.
Thus I'll throw this open to libvir-list to see if anyone has
an idea how to implement that ...
Reply-To set to libvir-list ...
At that point, I think the next step from libvirt is to send a
VIR_DOMAIN_EVENT_STOPPED_CRASHED domain event, correct?
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
4:22 a.m.
On Tue, Apr 07, 2009 at 04:19:42PM -0500, Hollis Blanchard wrote:
Hi Rich, your watchdog qemu patch is working fine for me (i6300esb,
default reset behavior), but I was wondering... how should libvirt find
out about the watchdog firing?
This falls into the general problem space of how does QEMU notify its
management app of interesting events. We already really want the
ability to be notify of ENOSPC errors in disks, and also would like
to know if the VM is paused for any reason outside our control.
There have been proposals to just print an async message to the
monitor upon events, that mgmt app could then parse. This is a little
fragile though, so for a long term solutiuon we really need the generic
libqemumonitor.so type API with formal async notification support.
For notification of the watchdog firing, I guess the answer depends
on what sort of action you've told QEMU todo. If the action is a
'shutdown', then there won't be much opportunity to notify the mgmt
app before QEMU exits. We could define a watchdog action of 'pause'
which just pauses the VM CPUs, and then notifies via the monitor
that the watchdog fired. The mgmt app could receive this, and then
destroy the VM if desired.
At that point, I think the next step from libvirt is to send a
VIR_DOMAIN_EVENT_STOPPED_CRASHED domain event, correct?
That would be the ideal event to emit if we could get a notification of
the fact that watchdog fired. If QEMU does the shutdown itself, then we
won't be able to distinguish this from a regular graceful VM shutdown
and so would just end up with VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN event
being emitted when we see QEMU exit.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:18 a.m.
New subject: [libvirt] Re: [PATCH] Hardware watchdog patch, version 6
Daniel P. Berrange wrote:
On Tue, Apr 07, 2009 at 04:19:42PM -0500, Hollis Blanchard wrote:
> Hi Rich, your watchdog qemu patch is working fine for me (i6300esb,
> default reset behavior), but I was wondering... how should libvirt find
> out about the watchdog firing?
>
This falls into the general problem space of how does QEMU notify its
management app of interesting events. We already really want the
ability to be notify of ENOSPC errors in disks, and also would like
to know if the VM is paused for any reason outside our control.
There have been proposals to just print an async message to the
monitor upon events, that mgmt app could then parse. This is a little
fragile though, so for a long term solutiuon we really need the generic
libqemumonitor.so type API with formal async notification support.
I just posted a patch series that demonstrate how I think it should
work. FWIW, I think notifications are orthogonal to libqemumonitor.so
and a non-human monitor mode.
Regards,
Anthony Liguori
9:35 a.m.
New subject: [libvirt] Re: [PATCH] Hardware watchdog patch, version 6
On Wed, Apr 08, 2009 at 09:18:55AM -0500, Anthony Liguori wrote:
Daniel P. Berrange wrote:
>On Tue, Apr 07, 2009 at 04:19:42PM -0500, Hollis Blanchard wrote:
>
>>Hi Rich, your watchdog qemu patch is working fine for me (i6300esb,
>>default reset behavior), but I was wondering... how should libvirt find
>>out about the watchdog firing?
>>
>
>This falls into the general problem space of how does QEMU notify its
>management app of interesting events. We already really want the
>ability to be notify of ENOSPC errors in disks, and also would like
>to know if the VM is paused for any reason outside our control.
>There have been proposals to just print an async message to the
>monitor upon events, that mgmt app could then parse. This is a little
>fragile though, so for a long term solutiuon we really need the generic
>libqemumonitor.so type API with formal async notification support.
>
I just posted a patch series that demonstrate how I think it should
work. FWIW, I think notifications are orthogonal to libqemumonitor.so
and a non-human monitor mode.
If we get a way to have async events without waiting for libqemumonitor.so
that'd make me very happy :-)
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5710
days inactive
5711
days old
4 comments
4 participants
participants (4)
-
Anthony Liguori -
Daniel P. Berrange -
Hollis Blanchard -
Richard W.M. Jones