From mboxrd@z Thu Jan  1 00:00:00 1970
From: Frediano Ziglio <frediano.ziglio@citrix.com>
Subject: Re: Domain Save Image Format proposal (draft B)
Date: Wed, 12 Feb 2014 18:16:29 +0000
Message-ID: <1392228989.10336.11.camel@hamster.uk.xensource.com>
References: <52F90A71.40802@citrix.com>
	<20140212163625.GE91459@deinos.phlegethon.org>
	<52FBAAE4.7010602@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <52FBAAE4.7010602@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>, "Xen-devel@lists.xen.org" <Xen-devel@lists.xen.org>, Shriram Rajagopalan <rshriram@cs.ubc.ca>
List-Id: xen-devel@lists.xenproject.org

On Wed, 2014-02-12 at 17:09 +0000, David Vrabel wrote:
> 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.
> 

<paranoia mode>
I think it depends if you want to detect some type of corruption. Images
can be send through wire or saved to disk and then restored. Although
network put a lot of checks and disk know when data are corrupted in the
physical layer (as sectors have CRCs too) corruptions occurring on
memory transfers or bus (like SATA or PCI) are not detected.

CRC could also be useful for Remus to detect corruption and request
updating it.
</paranoia mode>

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

Frediano