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

[Christopher Covington]

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

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project