[pve-devel] live storage migration v9

[Alexandre DERUMIER]

>>
>>Fabian also pointed out one other important missing piece: Currently
>>this series completely ignores the 'migration_insecure' option and
>>always uses a raw tcp stream.
>>
>>We should instead use the same pattern as for the migration itself and
>>tunnel unix sockets over the 'mtunnel' (you can gather a the tunnel list
>>in the run_command() call in phase2() which goes through the `migration
>>listens on ...` matches and build an array of tunnels you then pass to
>>`fork_mtunnel()` the same way it works for the migration itself.
>>`fork_mtunnel()` has to be changed to accept multiple tunnels (which it
>>can simply pass as multiple `-L` options to t he same ssh command).


Note that qemu support tls natively, both for migration && nbd

https://www.berrange.com/posts/2016/04/05/improving-qemu-security-part-5-tls-support-for-nbd-server-client/

Isn't it better to implement this than an ssh tunnel ?

ssh is cpu usage limited to 1core, and it's almost impossible to reach more than 600-700mbits.



----- Mail original -----
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Mercredi 4 Janvier 2017 15:59:33
Objet: Re: [pve-devel] live storage migration v9

On Tue, Jan 03, 2017 at 04:06:22PM +0100, Wolfgang Bumiller wrote: 
> On Tue, Jan 03, 2017 at 03:03:11PM +0100, Alexandre Derumier wrote: 
> > changelog : 
> > - add suspend or freezefs for live vm clone 
> > - return in socat tunnel close if no pid exist 
> 
> I'll test this series tomorrow and give more feedback afterwards. 

Okay, it seems to work much better now. 
I added some inline comments to the socat patch. 

Fabian also pointed out one other important missing piece: Currently 
this series completely ignores the 'migration_insecure' option and 
always uses a raw tcp stream. 

We should instead use the same pattern as for the migration itself and 
tunnel unix sockets over the 'mtunnel' (you can gather a the tunnel list 
in the run_command() call in phase2() which goes through the `migration 
listens on ...` matches and build an array of tunnels you then pass to 
`fork_mtunnel()` the same way it works for the migration itself. 
`fork_mtunnel()` has to be changed to accept multiple tunnels (which it 
can simply pass as multiple `-L` options to t he same ssh command).