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

[Pavel Emelyanov]

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