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/
Home Products Support Community News


[Xen-devel] save image file format

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] save image file format
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Thu, 14 Sep 2006 13:14:50 +0100
Delivery-date: Thu, 14 Sep 2006 05:15:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
I brought this up with a few people at the summit, but I thought I'd
gauge interest here.

The current format used for save files and migration has a number of

1) it's not self-identifying (word size, machine type)
2) it's unversioned
3) it misses some useful meta information (e.g. xen version)
4) it's not easily extendable
5) it needlessly uses a different format from core files, requiring a
debugger to implement both formats as a backend if support for both is

1) and 5) makes implementing a debugger that works sanely very
difficult. 2) and 4) are likely to significantly complicate things in
the future, whilst 3) makes debugging a lot less useful.

As the migration format needs modifying for HVM anyway as Intel
presented, and presumably for XML config changes, I suggest that a new
format be put in place during the 3.0.4 timeline. Are there other people
interested in such a change?

I was thinking of a simple ELF-like format. One problem is that of
migration's streaming format, but this could be dealt with as a special
case (e.g. that section's size is explicitly labelled as '0' to mean
"special case").

There also remains the question of supporting older Xens. I don't
believe that anything other than migration back-compatibility is
interesting in this case, and presumably this can be handled reasonably
easily by a slight refactoring of xc_linux_{save,restore} (on the
presumption that people will want to migrate both to and from such older
dom0's), and falling back to compat mode when the new negotation API


Xen-devel mailing list

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