[CRIU] Reg unix stream checkpointing and other issues.

[Pavel Emelyanov]

On 09/11/2014 07:48 PM, Sanidhya Kashyap wrote:
> Thanks Pavel for the response. I have some more questions.
> 
> On Thu, Sep 11, 2014 at 7:19 AM, Pavel Emelyanov <xemul at parallels.com> wrote:
>>
>>> Then, I went on to try checkpointing of two processes in one shot i.e.
>>
>> CRIU cannot do it. Only one pid at a time.
>>
> 
> But, I can extend the criu to consider two or more processes?

Sure!

>>
>> This is AIO mapping. We're working on supporting this, patches are
>> expected to appear by v1.4 :)
>>
> 
> That's great!! When can I expect the 1.4 version? Or are those patches
> already upstreamed?

Our release policy is like this: http://criu.org/Release_schedule
But note, that releases are time-driven, not feature-driven. So if
the patches are not ready till 1.4 they are delayed till next release.

>>> But still, I have some questions which I would like to know:
>>> 1) How can I dump the another half of unix socket connection?
>>
>> Without the process, that owns it, it's impossible. At least, without
>> patching the kernel.
>>
>>> 2) Even if I am able to dump the another half, will the application
>>> work when I restore it or the another half needs to do something?
>>
>> With unix connection, if you dump both ends, you should restore
>> both ends too.
>>
> 
> Yup, I am going to do that! I will eventually restore both or multiple
> resources sharing the same resource.

Great!

>>> 3) In what conditions, do I see uncollected sockets, and non-regular mappings?
>>
>> "Uncollected sockets" is pretty much harmless message. If I'm not
>> mistaken, it was left from the times when we didn't support IPV6
>> and netlink sockets.
>>
>> Non regular mappings are mappings of files, that CRIU cannot dump.
>> It can be a device mapping or AIO.
>>
> 
> I guess for the device mapping, we have to write separate mechanism to
> work with those.

Yes. We have plugins engine (http://criu.org/Plugins). In case we'll
need to support devices, we will add plugin hooks into respective places.
But so far we haven't met this requirement.

>>> 5) Is there a possibility of checkpointing multiple processes which
>>> are sharing the resources on a single host, like unix stream and
>>> types? If yes, then what is the way to achieve it?
>>
>> When you specify a PID of a process, CRIU dumps the whole subtree
>> of tasks sitting under it. If you want to dump two subtrees, you
>> need to patch CRIU. It can do it in theory, but there's no such
>> API yet.
> 
> I am more *interested* in this prospect and would like to know how is
> it possible to do?
> By API do you mean kernel API or something else?

I mean CRIU API. We have 3 of them (http://criu.org/API_compliance).
As far as multiple PIDs feature is concerned, we will probably need to:

1. make the --tree option accept the comma/colon-separated list
2. fix the pstree (process tree) restore code to bear with multiple
   root tasks
3. audit the code for checks for root process and think would they
   break or not (there are a couple of places about it)
4. test it. I'd suggest modifying the zdtm suite so that it launches,
   dumps and restores more than one test at a time

> I shall be grateful if you can give me some pointers.

Thanks,
Pavel