[CRIU] Disable dump of inet connections during checkpoint

[Marcos Lilljedahl]

Have you checked
https://lists.openvz.org/pipermail/criu/2016-May/028067.html ?

On Thu, Jun 16, 2016 at 1:53 PM, vikram kaul <kaul.vikram.kaul at gmail.com>
wrote:

> Hi, first post here.
> I am using Ross Boucher docker-checkpoint-restore branch to be able to C/R
> docker containers with active inet connections. Everything works perfectly
> if I am C/R a container and don't leave it running. On recreation, the new
> container acquires the same IP address and the inet connections are
> restored.
>
> However, my intention is to restore the state of the container into a new
> container with a different IP address; while leaving the origin container
> alive (--leave-running). If there are no inet connections, it works fine.
> But if there are active inet connections (I have only tested for TCP), the
> restore fails as below
>
> (00.595191)     13:     Restore: family 2 type 1 proto 6 port 22 state 1
> src_addr 172.17.0.2
> (00.595223)     13: Restoring TCP connection
> (00.595233)     13: Restoring TCP connection id 12 ino 7ab3
> (00.595273)     13:     Setting 1 queue seq to 4031116443
> (00.595283)     13:     Setting 2 queue seq to 3265504662
> (00.595316)     13: Error (sk-inet.c:721): Can't bind inet socket (id 18):
> Cannot assign requested address
> (00.596042)     11: Error (cr-restore.c:1350): 13 exited, status=1
> (00.604410) Error (cr-restore.c:1352): 4800 killed by signal 9
> (00.618489) Error (cr-restore.c:2182): Restoring FAILED.
>
> It makes sense since the address (172.17.0.2) can't be assigned - the new
> container is at 172.17.0.3
>
> In order to have a viable system, I would prefer that the inet connections
> not be dumped at all during checkpoint. However, there seems to be no
> options to do this at all.
>
> I presume that if such an option for criu dump (Special resources support)
> would be created. Perhaps we can call it --neglect-net. We could add logic,
> perhaps in collect_namespaces(..) not to call collect_net_namespaces(..) ?
>
> Not knowing the depths of the code and its intentions, would such a
> modification achieve what I want to get done ? Is this something that would
> be of long term interest to CRIU ? I presume I would also need to update
> the interface so that docker could pass on this argument to criu during the
> checkpoint call. I probably have to figure out that flow as well.
>
> Thanks
> Vikram
>
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160617/a4826ab3/attachment-0001.html>