[CRIU] Disable dump of inet connections during checkpoint

vikram kaul kaul.vikram.kaul at gmail.com
Thu Jun 16 09:53:47 PDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160616/a3aa1989/attachment.html>


More information about the CRIU mailing list