Re: [PATCH Remus v2 00/10] Remus support for Migration-v2

[Yang Hongyang <yanghy@cn.fujitsu.com>]

On 05/12/2015 05:40 PM, Andrew Cooper wrote:
> On 12/05/15 09:12, Yang Hongyang wrote:
>>
>>>>> That sounds like COLO wants a should_checkpoint() callback which
>>>>> separates the decision to make a checkpoint from the logic of
>>>>> implementing a checkpoint.
>>>>
>>>> We use checkpoint callback to do should_checkpoint() thing currently.
>>>> libxc will check the return value of checkpoint callback.
>>>
>>> But that causes a chicken & egg problem.
>>>
>>> I am planning to use a CHECKPOINT record to synchronise the transfer of
>>> ownership of the FD between libxc and libxl.  Therefore, a CHECKPOINT
>>> record must be in the stream ahead of the checkpoint() callback, as
>>> libxl will then write/read some records in itself.
>>
>> The record name CHECKPOINT seems do not match the thing what you are
>> planning to do, In this case I think END-OF-CHECKPOINT which represent
>> the
>> END of libxc side checkpoint is better, when libxc side checkpoint end,
>> libxc should transfer the ownership of FD to libxl and let libxl to
>> handle the following stream. libxl side can also use END-OF-CHECKPOINT
>> as a sign to hand the ownership of the FD to libxc.
>
> END_OF_CHECKPOINT implies the presence of START_OF_CHECKPOINT.  The
> current spec for CHECKPOINT is more of a sentinal value between
> checkpoints of data.
>
>>
>>>
>>> As a result, the checkpoint() callback itself can't be used to gate
>>> whether a CHECKPOINT record is written by libxc.
>>
>> I was wondering how you will do the FD transfer job?
>
> The FD needs to be readable/writable in both the libxl and
> libxl-save-helper processes.  The CHECKPOINT record simply signals a
> transfer of ownership.
>
>>>>> I have a 4th alternative in mind, but would like your feedback from my
>>>>> comments in this email first.
>>>>
>>>> So what's the 4th alternative?
>>>
>>> I have some corrections to my patch series based on David's feedback,
>>> and your comments.  After that, it should hopefully be far easier to
>>> describe.
>>
>> OK, I've addressed all comments on my series and wait for your series
>> to continue :-)
>
> Sent.  Sorry for the delay (I also have some XenServer issues I am
> working on atm).

Never mind, and thank you very much for the quick turnaround! The design
looks more clear now, It really helps me a lot!

>
> ~Andrew
> .
>

-- 
Thanks,
Yang.