[Libvir] virDomainDump() API (equivalent to xm dump) in libvirt?

[Daniel Veillard]

On Thu, Nov 09, 2006 at 11:32:41AM +0100, Karel Zak wrote:
> On Fri, Nov 03, 2006 at 10:53:57AM -0500, Daniel Veillard wrote:
> > 
> >   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.
> 
>  Is there any policy what should be included in the library? I think
>  we will see many virtualization projects and an intersection between
>  all projects could be very small. From my point of view include to
>  the library something less generic is not big problem if we provide
>  API with a "non-implemented" (ENOSYS) return codes.

  A very specific API is in my experience a wrong one, you end up
accumulating specific APIs instead of finding the right one which 
expose a good semantic. 

  Please forget about "an integer specific return code is good
enough" we clearly aren't following that path, c.f.
    http://libvirt.org/errors.html
raising unavailable errors is a good point though.

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/