[pve-devel] live storage migration v9
Alexandre DERUMIER
aderumier at odiso.com
Wed Jan 4 17:20:37 CET 2017
>>
>>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).
More information about the pve-devel
mailing list