[CRIU] p.haul and lxc

[Ruslan Kuprieiev]

On 14.11.2014 11:09, Pavel Emelyanov wrote:
> On 11/14/2014 01:06 AM, Tycho Andersen wrote:
>> Finally, a minor conceptual change is that it would be nice to be able to set
>> up the channel that p.haul communicates over (e.g. a TLS socket or so), vs.
>> just having p.haul do a connect() over a raw socket. If nothing else, I think
>> we can just implement some other version of the `rpc_proxy` class to do this.
> Yes, Ruslan is working on it. He implemented the ssh tunnel, but I agree, that
> there should be an option to use the pre-established channel.

I could make my ssh wrapper 
<https://github.com/efiop/p.haul/blob/ssh_bash/p.haul-ssh> use 
pre-established ssh connection using
multiplexing as it uses it anyway =).

I've mentioned before, that we have a problem there with the current 
page-server
implementation. It uses _plain_ socket and low level stuff like 
splice(), which makes
it impossible to use ssl or ssh  wrappers(you can't just get fd and 
write() to it).
So currently we should use some kind of local proxy to make p.haul write to
local tcp socket(can't use socketpair. as they are 2 unix sockets and 
splice() doesn't
support them) and redirect it outside.
Maybe we should consider making criu transfer _all_ images(not only 
pages) and
use a ssl inside. Even though i'm not sure that we should use criu to 
transfer something
at all. I mean, if it is made to checkpoint\restore stuff, why make it 
deal with transferring?
Especially when there are a lot of feature-rich utilities that deal with 
transferring much
better(even though page-server is faster =)).

> Also note one thing. Currently in p.haul there are two channels -- one for RPC
> commands and the other one for memory (pre-)dumps. The latter is the socket
> that is fed to criu pre-dump, dump and page-server actions. With pre-established
> channel we'll have to do something about it. And pushing control commands AND
> memory over the same socket doesn't seem as the good solution to me.
>
> And one more thing about channels :) There are cases when we have to copy file
> system to remote host. IIRC you used rsync in your demo :) So we will need the
> 3rd channel. Can we make the channels set-up be independent from the p.haul
> caller, i.e. p.haul should have an ability to set channels himself. Somehow.
>
>> Do these sound reasonable? Does anyone have any thoughts?
> Thanks for joining the p.haul efforts :)
>
>
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20141114/9148d289/attachment.html>