All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Veillard <veillard@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: [Libvir] virDomainDump() API (equivalent to xm dump) in libvirt?
Date: Fri, 3 Nov 2006 10:53:57 -0500	[thread overview]
Message-ID: <20061103155357.GP28384@redhat.com> (raw)
In-Reply-To: <1162568298.4518.477.camel@rei.boston.devel.redhat.com>

On Fri, Nov 03, 2006 at 10:38:18AM -0500, Lon Hohberger wrote:
> There's already one for saving live domains:
> 
> int virDomainSave(virDomainPtr domain, const char *to);
> 
> Why not use a similar API for a function which does the equivalent of
> 'xm dump' ?

  I assume you mean 'xm dump-core' actually 

> int virDomainDump(virDomainPtr domain, const char *to, int flags);
> 
> Create a kernel dump of the domain in the path contained in *to.  This
> API must fail if the domain is not in a panicked/crashed state.
> If you set the lowest-bit in flags, however, you can override this
> behavior: if the lowest bit is set, the domain will first be crashed
> (similar to SysRq-C) - then a dump will be taken from that.
> 
> 
> Why?
> 
> In the event that a cluster node needs to fence a Xen domain (or other
> management tools, to be sure), we could use the API to generate a core
> of the domain (if it panicked) to help debug the problem prior to
> restarting the domain.
> 
> The 'crash-before-dump' bit is just something someone might want to use
> at some point; I don't think it is absolutely necessary - but it doesn't
> hurt anything either.

  Okay I can see how this would be useful, the questions I would have would be:
    - how generic is this, i.e. suppose a different hypervisor back-end
      would this still make sense. I guess yes, for example with an UML
      back-end we could check the process status and force a dump with a
      signal and move the core to the given file not trivial but same semantic
      would be doable.
    - can we implement it with current xen, again yes, we should be able
      if we have a full connection (root) to do the same as 'xm dump-core'
    - is the API clean enough, I guess the semantic is relatively clear
      instead of stating 'If you set the lowest-bit in flags' I would rather
      define a DumpFlags enum and state that flags is an or'ing of any of them
      I would probably name the function virDomainDumpCore though to not
      confuse with virDomainSave 

 So yes, why not, you want to work on it ? Or should I (or any candidate).

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/



  reply	other threads:[~2006-11-03 15:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-03 15:38 [Cluster-devel] virDomainDump() API (equivalent to xm dump) in libvirt? Lon Hohberger
2006-11-03 15:53 ` Daniel Veillard [this message]
2006-11-03 16:36   ` [Cluster-devel] Re: [Libvir] " Lon Hohberger
2006-11-03 16:40     ` Lon Hohberger
2006-11-03 16:56     ` Daniel Veillard
2006-11-16 15:36       ` Daniel Veillard
2006-11-22 17:01         ` Daniel Veillard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061103155357.GP28384@redhat.com \
    --to=veillard@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.