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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/07/13 10:32, Ian Campbell wrote:
> 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.
>
>

Ok - I will respin to that effect.

~Andrew

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