Re: [Xen-devel] Domain Save Image Format proposal (draft B)

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 12/02/14 16:36, Tim Deegan wrote:
> Hi,
> 
> This draft has my wholehearted support.  Even without addressing any
> of the points under discussion something along these lines would be a
> vast improvement on the current format.
> 
> I have two general questions:
> 
>  - The existing save-format definition is spread across a number of
>    places: libxc for hypervisor state, qemu for DM state, and the main
>    toolstack (libxl/xend/xapi/&c) for other config runes and a general
>    wrapper.  This is clearly a reworking of the libxc parts -- do
>    you think there's anything currently defined elsewhere that belongs
>    in this spec?

I was considering this format as a container for those blobs, but I
think there should be enough flexibility that additional things could be
moved into the spec in the future.

>  - Have you given any thought to making this into a wire protocol
>    rather than just a file format?  Would there be any benefit to
>    having records individually acked by the receiver in a live
>    migration, or having the receiver send instructions about
>    compatibility?  Or is that again left to the toolstack to manage?

I don't see how having the restorer send anything back to the saver
would work with image files[1] so any two way stuff must be optional so
this can be left for future.

Ian J had some suggestions for how to handle compatibility better
without having the restorer report its capabilities.

>> checksum     CRC-32 checksum of the record body (including any trailing
>>              padding), or 0x00000000 if the checksum field is invalid.
> 
> Apart from any discussion of the merits of per-record vs whole-file
> checksums, it would be useful for this checksum to cover the header
> too.  E.g., by declaring it to be the checksum of header+data where
> the checksum field is 0, or by declaring that it shall be that pattern
> which causes the finished header+data to checksum to 0.

A single checksum for a multi GB file doesn't seem robust enough, which
is why I made it per-record.  Per-record checksums also mean you can
discard records the restorer isn't interested in without having to read
them to calculate the checksum.

I'm not entirely convinced by the usefulness of checksums, though.  If
no one else thinks they would be useful I'll probably drop them.

>> P2M
>> ---
[...]
> The current save record doesn't contain the p2m itself, but rather the
> p2m_frame_list, an array of the MFNs (in the save record, PFNs) that
> hold the actual p2m.  Frames in that list are used to populate the p2m
> as memory is allocated on the receiving side.

Er. Yes, I got confused by the code here and misunderstood it.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel