[pve-devel] live storage migration v9

[Alexandre DERUMIER]

Hi Fabian,

>>I see two ways to improve this: 
>>
>>- switch the migration from the current binary "--online" switch to a 
>>new "mode" switch with several values (e.g., "offline", "online" and 
>>"online-mirror" - but I don't really care about the naming here ;)) 
>>- keep the "--online" switch and a new additional flag (e.g. 
>>"--with-local-disks") that enables this new migration type 

>>the first one would be more consistent with the way we handle a similar 
>>situation for vzdump, and also allows easy extension in case new modes 
>>are introduced[2]. OTOH finding good names for the modes might not be 
>>that easy ;) also I am not sure how this can be displayed in an easy to 
>>understand way on the GUI, although a smart default value selection 
>>might soften the impact here. 

>>the second one would work very well for the current situation and is 
>>also very nicely implementable on the GUI. adding other extra flags 
>>would quickly cause this to become very confusing (and also error prone 
>>when implementing, because checking one parameter is easier than 
>>checking a multitude of flag combinations). 


they are also the "-targetstorage" option, which is optionnal currently,
to define the destination local storage.

(user could migrate from local zfs to local lvm for example).

Currently I force the storage migration if any local disk is detected,
and target local storage with same name is available.

Maybe could we simply force the usage of "-targetstorage", to enable storage migration ?
So, in GUI, it could be a simple dropdown list with remote local storage list.

what do you think about this ?


----- Mail original -----
De: "Fabian Grünbichler" <f.gruenbichler at proxmox.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>
Cc: "aderumier" <aderumier at odiso.com>
Envoyé: Mercredi 4 Janvier 2017 16:52:56
Objet: Re: [pve-devel] live storage migration v9

On Wed, Jan 04, 2017 at 03:59:33PM +0100, Wolfgang Bumiller wrote: 
> 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. 

some further high-level input from my side - I already remarked this on 
an earlier version of this patch set[1], which probably got lost in the 
huge amount of mails, so here it goes again ;) 

I think that changing the semantics of the --online migration migration 
like this has the potential to confuse and/or hurt users, especially 
since mirroring the local disks can have a severe peformance impact! 

I see two ways to improve this: 

- switch the migration from the current binary "--online" switch to a 
new "mode" switch with several values (e.g., "offline", "online" and 
"online-mirror" - but I don't really care about the naming here ;)) 
- keep the "--online" switch and a new additional flag (e.g. 
"--with-local-disks") that enables this new migration type 

the first one would be more consistent with the way we handle a similar 
situation for vzdump, and also allows easy extension in case new modes 
are introduced[2]. OTOH finding good names for the modes might not be 
that easy ;) also I am not sure how this can be displayed in an easy to 
understand way on the GUI, although a smart default value selection 
might soften the impact here. 

the second one would work very well for the current situation and is 
also very nicely implementable on the GUI. adding other extra flags 
would quickly cause this to become very confusing (and also error prone 
when implementing, because checking one parameter is easier than 
checking a multitude of flag combinations). 

another questions is how we want to handle this issue on the LXC side, 
to me it looks like the mode switch variant is more easily adaptable for 
a consistent solution. 

since all of this is not (directly) related to your patch set and the 
remaining issues raised by Wolfgang AFAICT don't contain any 
showstoppers that require major refactoring, it should be possible to 
discuss the mode vs. flag thing (and implement whatever seems 
appropriate) separately, and then either you rebase your final patch set 
one last time, or we do it for you. 

(I'd love to get some feedback this time :P) 

1: v2, in <20161020090525.2brusypquumvsprw at nora.maurer-it.com> 
2: e.g., one interesting possibility would be a "minimal downtime" 
offline migration for ZFS-only guests that works with a two-phase zfs 
send/receive, because this would combine the nice properties of the 
current offline migration on ZFS (keeps snapshots!) with the added 
benefit of vastly reducing down time for most use cases.