Re: [Xen-devel] [PATCH v2 COLOPre 10/13] tools/libxl: Add back channel to allow migration target send data back

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-06-15 at 09:38 +0800, Yang Hongyang wrote:
> 
> On 06/12/2015 11:04 PM, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] [PATCH v2 COLOPre 10/13] tools/libxl: Add 
> > back channel to allow migration target send data back"):
> >> On Mon, Jun 08, 2015 at 11:43:14AM +0800, Yang Hongyang wrote:
> >>> From: Wen Congyang <wency@xxxxxxxxxxxxxx>
> >>>
> >>> In colo mode, slave needs to send data to master, but the io_fd
> >>> only can be written in master, and only can be read in slave.
> >>> Save recv_fd in domain_suspend_state, and send_fd in
> >>> domain_create_state.
> > ...
> >>>   libxl_domain_restore_params = Struct("domain_restore_params", [
> >>>       ("checkpointed_stream", integer),
> >>> +    ("send_fd", integer),
> >>
> >> I'm not entirely sure if we want to bury an extra argument here.
> >>
> >> After looking at code I think you're trying to work around API
> >> limitation. I think we are safe to extend the API -- we've already done
> >> that before. See libxl.h around line 990.
> >>
> >> Ian and Ian, what do you think?
> >
> > I agree with you, Wei.  I don't think an fd should be in
> > libxl_domain_restore_params at all.
> 
> Then I'll just extend the params of libxl_domain_create_restore().

One question first: is it really to be expected that send_fd and recv_fd
will be different, as opposed to the bidirectional data going over the
same socket?

> 
> >
> > We need to understand what the API semantics are.  Are are going to
> > introduce a new libxl API entrypoint ?  We already have
> > libxl_domain_remus_start.
> 
> We use libxl_domain_remus_start for COLO. COLO is an option of "xl remus".
> 
> >
> > Ian.
> > .
> >
> 



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