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

[Xen-devel] save image file format? and [RFC] tmem save/restore/migrate

To: "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] save image file format? and [RFC] tmem save/restore/migrate
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 17 Jun 2009 16:00:30 -0700 (PDT)
Cc: John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 17 Jun 2009 16:01:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Is there any documentation on the format of the file/stream
used for save/restore/migrate?  Or is it just a sequence of
chunks of bytes pre-defined only by the ordering of the
save/restore code?

I found this 2006 xen-devel thread, but it doesn't look like
it (other than hvm additions) ever happened?  E.g. still
no versioning, self-identification, extensibility?

http://lists.xensource.com/archives/html/xen-devel/2006-09/msg00440.html

I'm starting to look at save/restore/migrate for tmem and will
need to communicate the following information via file/stream:

- pool id and characteristics (a small number of bytes of data),
  for some small number of pools
- for some classes of pools, some number of "pages" of data,
  each page consisting of a "handle" (128 bits) and PAGE_SIZE
  bytes of data associated with that handle
- for some of these pages of data, a handle+invalidate (see below)
- (optional) in some cases the pages will be pre-compressed;
  each can be decompressed on the source side and recompressed
  on the destination side, but this seems a sad waste of
  cpu cycles (though necessary if the compression algorithm
  were different on source and destination); if possible,
  save/transmit non-decompressed data

Note that for the pages of data, dirtying during migration
is not possible, however invalidation IS possible.  E.g.
unlike normally addressable pages which may be transmitted
multiple times during a live migration, a transmitted
tmem page (handle and data) will be transmitted only once,
but may be followed at some point with a handle+invalidate.

The ordering of tmem info/pages vs current saved info/data
is flexible, but the number of pages could be very large,
so for live migrate, transmission should NOT be postponed
until the "final pass" of normal page transmission (e.g.
after the domain has been paused on the source machine).

I also need code to verify that the destination has tmem
support and it is enabled.  Only PV domains can use tmem
so no HVM changes should be necessary.

Any pointers or suggestions welcome, especially any thoughts
on changes that might be required above libxc such as in
python code or (heaven forbid) ioemu/qemu.

Thanks for any help!
Dan

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