<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 14.11.2014 11:09, Pavel Emelyanov
wrote:<br>
</div>
<blockquote cite="mid:5465C6B0.1010305@parallels.com" type="cite">
<pre wrap="">On 11/14/2014 01:06 AM, Tycho Andersen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
I could make my <a
href="https://github.com/efiop/p.haul/blob/ssh_bash/p.haul-ssh">ssh
wrapper</a> use pre-established ssh connection using<br>
multiplexing as it uses it anyway =).<br>
<br>
I've mentioned before, that we have a problem there with the current
page-server<br>
implementation. It uses _plain_ socket and low level stuff like
splice(), which makes<br>
it impossible to use ssl or ssh wrappers(you can't just get fd and
write() to it).<br>
So currently we should use some kind of local proxy to make p.haul
write to<br>
local tcp socket(can't use socketpair. as they are 2 unix sockets
and splice() doesn't<br>
support them) and redirect it outside.<br>
Maybe we should consider making criu transfer _all_ images(not only
pages) and<br>
use a ssl inside. Even though i'm not sure that we should use criu
to transfer something<br>
at all. I mean, if it is made to checkpoint\restore stuff, why make
it deal with transferring?<br>
Especially when there are a lot of feature-rich utilities that deal
with transferring much<br>
better(even though page-server is faster =)).<br>
<br>
<blockquote cite="mid:5465C6B0.1010305@parallels.com" type="cite">
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">Do these sound reasonable? Does anyone have any thoughts?
</pre>
</blockquote>
<pre wrap="">
Thanks for joining the p.haul efforts :)
_______________________________________________
CRIU mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CRIU@openvz.org">CRIU@openvz.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openvz.org/mailman/listinfo/criu">https://lists.openvz.org/mailman/listinfo/criu</a>
</pre>
</blockquote>
<br>
</body>
</html>