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. For 'xm dump' / virDomainDump() I think its pretty clear all the major virtualization technologies have some method of dumping a VM's state so ths API seems sound to me too. 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 -=|