WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] save image file format? and [RFC] tmem save/restore/migrate
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Thu, 18 Jun 2009 08:26:20 -0400
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Gianluca Guida <Gianluca.Guida@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 18 Jun 2009 05:26:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090618120558.GJ16056@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <f832a6fa-b148-41f2-baa3-d987ecfb2a55@default> <20090618085158.GE16056@xxxxxxxxxxxxxxxxxxxxx> <20090618113924.GB17990@xxxxxxxxxxxxxxxxx> <4A3A2CE1.2010100@xxxxxxxxxxxxx> <20090618120558.GJ16056@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Thu, Jun 18, 2009 at 01:05:58PM +0100, Tim Deegan wrote:

> At 13:02 +0100 on 18 Jun (1245330161), Stefano Stabellini wrote:
> > At least in theory is certainly feasible: just a matter or registering
> > another savevm function for a record called "cpu" or "vcpu", that would
> > take care of saving the guest memory using xc_domain_save.
> 
> Yuck.  You still need to add a bunch of metadata from xend that qemu
> doesn't know about, so you'll have to wrap the qemu output in another
> file format already.

Why? The qemu format is extensible, no? Why isn't this just an .sxp
SaveStateEntry ?

Think about it from the point of view of a save-file inspector. If they
can write the container-unwrapping code just once, and have specific
methods for Xen-particular or kvm-particular sections, that seems like a
clear win.

> 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. But heck, if you like, make libxc write out qemu format.

> > The qemu people are also maintaing save record compatibility now, so we
> > are safe from that perspective.
> 
> 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.

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.

regards
john

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

<Prev in Thread] Current Thread [Next in Thread>