[CRIU] p.haul and lxc

[Pavel Emelyanov]

On 11/14/2014 04:43 PM, Ruslan Kuprieiev wrote:
> 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 =)).

The thing with page-server is not only about transferring. It's also about
merging new pages with old ones upon receive.

>> 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
>