<div dir="ltr">Have you checked <a href="https://lists.openvz.org/pipermail/criu/2016-May/028067.html">https://lists.openvz.org/pipermail/criu/2016-May/028067.html</a> ?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 16, 2016 at 1:53 PM, vikram kaul <span dir="ltr"><<a href="mailto:kaul.vikram.kaul@gmail.com" target="_blank">kaul.vikram.kaul@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi, first post here.<div>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.</div><div><br></div><div>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</div><div><br></div><div><div>(00.595191) 13: Restore: family 2 type 1 proto 6 port 22 state 1 src_addr 172.17.0.2</div><div>(00.595223) 13: Restoring TCP connection</div><div>(00.595233) 13: Restoring TCP connection id 12 ino 7ab3</div><div>(00.595273) 13: Setting 1 queue seq to 4031116443</div><div>(00.595283) 13: Setting 2 queue seq to 3265504662</div><div>(00.595316) 13: Error (sk-inet.c:721): Can't bind inet socket (id 18): Cannot assign requested address</div><div>(00.596042) 11: Error (cr-restore.c:1350): 13 exited, status=1</div><div>(00.604410) Error (cr-restore.c:1352): 4800 killed by signal 9</div><div>(00.618489) Error (cr-restore.c:2182): Restoring FAILED.</div></div><div><br></div><div>It makes sense since the address (172.17.0.2) can't be assigned - the new container is at 172.17.0.3</div><div><br></div><div>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.</div><div><br></div><div>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(..) ? </div><div><br></div><div>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.</div><div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><div>Vikram</div></font></span></div>
<br>_______________________________________________<br>
CRIU mailing list<br>
<a href="mailto:CRIU@openvz.org">CRIU@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/criu" rel="noreferrer" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
<br></blockquote></div><br></div>