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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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)

~Andrew

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