[CRIU] [PATCH 0/3] p.haul: ssh tunneling, v5

Ruslan Kuprieiev kupruser at gmail.com
Fri Oct 31 03:18:15 PDT 2014


On 29.10.2014 11:29, Ruslan Kuprieiev wrote:
> On 29.10.2014 10:03, Pavel Emelyanov wrote:
>> On 10/28/2014 01:18 AM, Ruslan Kuprieiev wrote:
>>> v2, use ssh tunnel by default, enhanced opts handling
>>> v3, send addr to the client
>>> v4, use rpc to send socket name
>>> v5, add --no-ssh option
>>>
>>> Ruslan Kuprieiev (3):
>>>    p.haul: do not use getsockname() as a hash_name, v4
>>>    p.haul: add --port option to p.haul-service
>>>    p.haul: use ssh tunneling and controll it with ssh* cmdline opts, v2
>>>
>>>   p.haul          | 17 +++++++++++++++--
>>>   p.haul-service  | 15 ++++++++++++++-
>>>   p_haul_iters.py |  6 +++---
>>>   ssh_tunnel.py   | 36 ++++++++++++++++++++++++++++++++++++
>>>   util.py         | 10 ++++++++++
>>>   xem_rpc.py      | 53 ++++++++++++++++++++++++++++++++++++++---------------
>>>   6 files changed, 116 insertions(+), 21 deletions(-)
>>>   create mode 100644 ssh_tunnel.py
>>>
>> I'm still not happy with the fact the spawned ssh with port forwarding
>> takes time to prepare and we have to retry connecting to it.
>>
>> I was today told about the paramiko package --https://pypi.python.org/pypi/paramiko/
>> Isn't it better to utilize this one?
>
> I've tried to use paramiko, but it is pretty slow and for port 
> forwarding requires
> writing own local server 
> <https://github.com/paramiko/paramiko/blob/master/demos/forward.py> in 
> python. It is flexible, but it looks like an overkill to me.
>

I did some tests on p.haul/test/zdtm and here is what i've got:
ssh + Popen = ~0.8 sec total.
paramiko + python server = ~1.5 sec total.

>> Another question -- how does this machinery works in qemu? Can you find out?
>
> Qemu? Ok, i'll try.
>

Couldn't find anything suitable for our case.

>> And the last thing. Our vzmigrate guys tell, that in Python it might be
>> MUCH simpler to do this another way. First, you connect to ssh, authorize
>> yourself, then generate an openssl sertificate and then use one to establish
>> other connections between p.haul and p.haul-service. Maybe RPC control
>> socket can just re-use the ssh channel, but data socket is better to work
>> over openssl. Can you research this too?
>
> Well, the problem here is we will still need to do some kind of 
> forwarding,
> because page-server uses splice(), but openssl sockets are not meant to
> be used with it. They can't be even used with regular read(sk...) call.
> I mean, you cant just get fd of ssl socket and use regular calls.
>
> Btw, i'm not sure that:
> 1) authorizing through ssh
> 2) gen ssl keys
> 3) transfer ssl keys
> 4) create ssl socket
> 5) transfer data
> is faster than:
> 1) create ssh tunnel
> 2) transfer data
>
> I think, that using ssh tunneling is the most suitable way here.
>

So, what do you think?

>> Thanks,
>> Pavel
>>
>

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


More information about the CRIU mailing list