| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] save image file format? and [RFC] tmem save/restore/migr
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
|
|
|
| |
|
Home