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 -=|