On Thu, Nov 18, 2010 at 10:56:47AM +0000, Daniel P. Berrange wrote:
On Wed, Nov 17, 2010 at 03:45:05PM +0800, Hu Tao wrote:
> This patch series adds support of auto-dump on watchdog event in
> libvirtd. If a qemu guest is configured with a watchdog device and
> libvirtd receives a watchdog event from the guest, it can do
> something on the guest, currently `dump' action is defined.
>
> This patch series adds a new watchdog action `managed', it has a
> subaction wich indicates the action libvirtd will take on a watchdog
> event.
>
> The meaning of subaction_arg depends on subaction. If subaction is
> `dump', then subaction_arg defines a folder path into which libvirtd
> saves dumpfile.
>
> An example:
>
> <watchdog model='i6300esb' action='managed'
subaction='dump' subaction_arg='/mnt/data/dumps'>
Is there any need to have both 'action' and 'subaction' here ? I
would think we could just have action='dump' on its own.
Yes, it's better than having an extra subaction. I'll change this.
One interesting side not, from the Xen driver we already have a
bit of XML syntax
<on_crash>destroy|restart|rename|preserve|coredump-destroy|coredump-restart</on_crash>
Which we never use with the QEMU driver so far, since we can't
detect whether a guest kernel has crashed or not. I'm wondering
if we shouldn't let one of the watchdog actions be 'crash'
and then take whatever action is specified in <on_crash>.
For qemu we can only tell if a guest is crashed or not by configuring a
watchdog device (or someone can tell me is there a better way to do
this?), this is the reason I define another action for watchdog.
If we only specify an action in <on_crash>(dump in this example), but
at the same time watchdog action is destroy, then we will have no
chance to dump guest on a watchdog event because qemu have already
destroyed it.
For the dump location, I think it would suffice to just have a
parameter set globally in /etc/libvirt/qemu.conf (cf XenD which
just always dumps core to /var/lib/xen/dump/$NAME)
--
Thanks,
Hu Tao