[CRIU] p.haul and lxc

Ruslan Kuprieiev kupruser at gmail.com
Fri Nov 14 04:58:36 PST 2014


On 14.11.2014 13:50, Pavel Emelyanov wrote:
> 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.

Oh... I forgot about that.



More information about the CRIU mailing list