[CRIU] [PATCH 00/11] p.haul: implement migration in so-called revive mode

[Nikita Spiridonov]

On Thu, 2016-03-17 at 22:38 +0300, Pavel Emelyanov wrote:
> On 03/17/2016 07:06 PM, Nikita Spiridonov wrote:
> > On Wed, 2016-03-16 at 10:37 -0400, Christopher Covington wrote:
> >> On 03/15/2016 10:04 AM, Nikita Spiridonov wrote:
> >>> On Mon, 2016-03-14 at 13:50 -0400, Christopher Covington wrote:
> >>>> On 03/04/2016 04:31 AM, Nikita Spiridonov wrote:
> >>>>> Implement so-called revive migration mode which migrate fs to target
> >>>>> host iteratively while possible, stop process tree on source host
> >>>>> and start it on target host. C/r not used in this mode.
> >>>>
> >>>> What do you mean "C/r not used"? How do you start the process tree if
> >>>> not by running `criu restore` "r" on a set of images that were created
> >>>> by `criu dump` "c"?.
> >>>
> >>> It seems such migration mode relevant exclusively for containers
> >>> migration (Virtuozzo, LXC and so on). 
> >>>
> >>> For example, during Virtuozzo container migration in such mode we
> >>> migrate disks iteratively to target host, than stop container on source
> >>> side, handle final disks sync and start container on targer side. So,
> >>> finally, Virtuozzo core is implicitly responsible for process tree
> >>> restoration on target host, but actually it is another process tree
> >>> (since guest os was restarted).
> >>
> >> I might be misunderstanding, but I don't think "restoration" and
> >> "revive" are quite the right words for this. Entirely new processes are
> >> being created, most likely with different PIDs, etc. and in cases of
> >> dynamically spawned threads and processes, some nodes in the process
> >> tree may actually be missing until incoming requests or other stimuli
> >> occur. Perhaps process tree "re-initialization" is a clearer way to
> >> describe what's going on. From the software perspective, it's a lot like
> >> shutting down, changing out hardware and/or network connections, and
> >> powering back on. As for the flag, maybe call it something like
> >> --filesystem-only?
> >>
> >>> Such approach decrease downtime in comparison with manual stopping and
> >>> starting of container by end user since considerable part of container
> >>> fs already transferred to target host when container stopped.
> >>>
> >>> I know that such usage conflicts slightly with initial conception of
> >>> p.haul as process hauler, but it help to avoid fs migration code
> >>> duplication in other utilities.
> >>
> >> It sounds like a nice feature. I'm just trying to give feedback on the
> >> naming to hopefully make the feature easy for people to understand and
> >> use if it suits their needs.
> >>
> >> Cheers,
> >> Cov
> >>
> > 
> > I choose "revive" name as analogy to "live", but I agree that it sounds
> > confusing. Maybe something like "--mode=fsonly" is a better option.
> > Xemul, what do you think about modes terminology?
> 
> The simpler the better. If we're moving the fs part only and restore the
> container, then the --restart option would be more descriptive... I think.
> 
> -- Pavel

"restart" is okay for me, lets replace "--mode=revive" with
"--mode=restart" in v2 of patchset.