Re: [Xen-devel] [PATCH] tools/migrate: Fix regression when migrating from older version of Xen

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-07-15 at 15:24 +0100, Andrew Cooper wrote:
> On 11/07/13 12:43, Ian Campbell wrote:
> > On Thu, 2013-07-11 at 12:19 +0100, Andrew Cooper wrote:
> >> On 11/07/13 10:55, Ian Campbell wrote:
> >>> On Wed, 2013-07-10 at 20:19 +0100, Andrew Cooper wrote:
> >>>> Commit 00a4b65f8534c9e6521eab2e6ce796ae36037774 Sep 7 2010
> >>>>   "libxc: provide notification of final checkpoint to restore end"
> >>>> broke migration from any version of Xen using tools from prior to that 
> >>>> commit
> >>>>
> >>>> Older tools have no idea about an XC_SAVE_ID_LAST_CHECKPOINT, causing 
> >>>> newer
> >>>> tools xc_domain_restore() to start reading the qemu save record, as
> >>>> ctx->last_checkpoint is 0.
> >>> Can the receive not distinguish the case where it is receiving a
> >>> checkpoint stream from a regular one? Either via some property of the
> >>> stream or the parameters with which it was called?
> >>>
> >>> ctx->last_checkpoint should (be made to) only matter if you are doing
> >>> check pointing and I think we can mandate that checking pointing is only
> >>> supported between like versions of Xen. TBH it's a bit odd to send the
> >>> LAST_CHECKPOINT in anon-checkpoint stream anyway, but what's done is
> >>> done.
> >>>
> >>> Ian.
> >> Sending LAST_CHECKPOINT is the only thing which has allowed normal
> >> migration to work since this regression.
> >>
> >> I cant find any way of distinguishing a normal vs checkpointed migrate
> >> from the stream alone.  The save_callback->checkpoint function pointer
> >> may or may not be filled in by a toolstack, but is completely
> >> out-of-band as far as the migration stream is concerned.
> > I suppose your new last_generation-aware flag is similar to the "is a
> > checkpoint restore" lag which I was thinking of, but it somewhat easier
> > for the toolstack to know that it is receiving a checkpoint vs. normal
> > migration compared with magically knowing the version on the other end
> > of the connection.
> >
> > Ian.
> >
> 
> So is this an indication of this patch being a good fix for the problem?
> (I guess this is a pseudo-ping given no specific objection)

If it implements the semantics I describe then all you need to do is
change the name.

The reason I prefer a "incoming checkpointed stream" flag over a
"understands last checkpoint" is that the former is something the
toolstack knows about independently of the versions of Xen on either end
of the socket.

Ian.



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