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

[Ruslan Kuprieiev]

On 05.11.2014 13:14, Pavel Emelyanov wrote:
> On 10/31/2014 03:29 PM, Ruslan Kuprieiev wrote:
>> On 31.10.2014 11:27, Pavel Emelyanov wrote:
>>> On 10/31/2014 02:18 PM, Ruslan Kuprieiev wrote:
>>>> 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.
>>> OK. Plz, do one more attempt :) What if we ssh to remote host and launch the p.haul-service
>>> there via this ssh session, not in advance. Would that look nicer in the code?
>> Oh, thats sounds great. It could be easily arranged into existing tunnel
>> command:
>> ssh -o BatchMode=yes -L loc_port:localhost:rem_port user at rem
>> "p.haul-service --port rem_port"
>> So I still think that using paramiko will be an overkill. Or you insist
>> on using it?
> No, I just want to have the ssh tunnel that is easy to use and develop :)
> If paramiko is just painful, then using plain ssh is OK.
>

Oh, I see. Yes, i've tried using paramiko again, and it makes everything 
messy, because,
it is still an overkill. On the other hand Popen was a bit messy too. So 
i've created a
wrapper(written in sh) to handle establishing ssh tunnel and all related 
stuff. And it
looks great to me. I will present it after "[PATCH] p.haul: do not use 
getsockname() as a
hash_name, v5" and "[PATCH 0/3] make p.haul installable" will be considered.

>>>>>> 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.
>>> How does it work?
>>>
>>>
>> I didn't bother looking into source =), but judging from qemu wiki
>> it is somehow streaming images between src and dest. Which
>> doesn't seem suitable for us, as the heaviest imagages(pages) are
>> handled by our page-server.
>> .
>>