Re: [Xen-devel] save image file format? and [RFC] tmem save/restore/migrate

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Thu, Jun 18, 2009 at 01:43:05PM +0100, Tim Deegan wrote:

> At 13:26 +0100 on 18 Jun (1245331580), John Levon wrote:
> > > just layering for its own sake.  (Also, using qemu to save a PV guests 
> > > would be pretty wierd).
> > 
> > Why? We already use qemu for PV guests and that's only going to become
> > more common.
> 
> Is it?  AIUI the only thing we use qemu for in PV guests is the pvfb
> backend, which is just because nobody's put in a proper library
> interface to that code.

The console as well if xenconsoled isn't running.

> > > Yes, but their code-defines-format model is rubbish.
> > 
> > Maybe now is the time to help them fix that? It's really no worse than
> > Xen's code-defines-format model, headers or not.
> 
> Qemu's code-defines-format model is actually much better than the
> xend/libxc code-defines-format model. :)  But that's not to say it's the
> thing we should be copying.

Well, given we're agreed that we should have a document of /some/
specification, why not qemu's? Presumably we need to document the state
that qemu /does/ save for HVM guests anyway, so why not the whole thing?

> > If we do need a separate container format, let's use ELF like the core
> > files (slightly extended as I mentioned). Just not yet another format
> > when there's no need.
> 
> ELF could work; it gives us easy access to unpacking code in several
> languages.

I admit ELF is easier to work with. It's a shame qemu (and Xen!) didn't
use it from the start.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel