[pve-devel] live storage migration v9

[Fabian Grünbichler]

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.