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

[Nikita Spiridonov]

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?