RE: [Xen-devel] save image file format

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> 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
> problems:
> 
> 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 wanted

The plan is to fix much of this post 3.0.3 while integrating HVM
save/restore. Would be good to have your help on this.

save/restore is quite different from a core, so I'm not sure its worth
doing #5.

For the sake of optimizing IO, keeping the data pages aligned is
worthwhile (I also want to make support for RDMA during live relo easy
as well). For PV guest live relo we have to transfer page type info, and
there is some advantage to transferring this 'as we go' rather than in a
big batch at the end.

> 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 fails.

It's an interesting question whether we can get away with breaking old
saved images. We've never guaranteed stability of this ABI, but it would
be nice to retain backward compatibility if it's not too hard.

Ian

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