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

[Daniel P. Berrange]

On Wed, Nov 15, 2006 at 10:12:57AM +0100, Karel Zak wrote:
> 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? 

I think it fine to has some APIs which are not supported by every 
backend - as long as if QEMU gained that particular feature at a 
later date it would be possible to add it in. Take for example the
device hotplug stuff that micheal posted a patch for yesterday. The
original idea was to do an API based on Xen device id - this is clearly
not going to work for a QEMU backend, so we agreed passing in the device
XML blob is a better approach. Now even if we only ever implement the
hotplug stuff for Xen, this API at least gives us option of doing other
implementations if we need to.

>  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

Hopefully not - for most of the stuff we've discussed thus far we've
been able to come up with a representation that is not Xen specific.
I'm optimistic that we'll be able to continue to do this for other
commonly needed things. 

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|