[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] save image file format? and [RFC] tmem save/restore/migrate
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |