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

[Yang Hongyang <yanghy@xxxxxxxxxxxxxx>]

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.

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