[libvirt] Re: [PATCH] Hardware watchdog patch, version 6 (was: Re: [Qemu-devel] [PATCH] Hardware watchdog patch, version 5)
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
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
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 :|
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
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 :|
participants (4)
-
Anthony Liguori -
Daniel P. Berrange -
Hollis Blanchard -
Richard W.M. Jones