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

[Karel Zak]

On Tue, Nov 14, 2006 at 11:52:01PM +0000, Daniel P. Berrange wrote:
> 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 good sanity check for a proposal is to ask yourself - how would this
> be implemented & data represented for QEMU or  UserModeLinux, or VMWare. 
> If you can think of plausible implementations / representations then 
> that's a good sign the proposal isn't too Xen specific.

 Yes, I understand. But what if we found a feature which is supported
 by Xen and VMWare, but is not supported by QEMU? What if we will in
 future want to support other virtualization project which is poor for
 features? Is possible write libvirt based application which is really
 useful, but independent on a virtualization technology? 
 
 Nice example is linux kernel and alsa -- it supports many different
 sound cards with different features. The kernel doesn't disable use
 digital output for my Live! although this feature is not generic for
 all sound cards.
 
 Try implement to the virt-manager (or to the applet, or ...)
 migration of virtual machines. This is cool feature, but it's Xen
 specific -- it means you have to bypass libvirt :-( The result will
 be nice and clean libvirt and a lot of dirty applications with
 duplicate code which is specific for a technology. Is it expected
 result?

    Karel

-- 
 Karel Zak  <kzak at redhat.com>