[CRIU] Do anyone knows how to migrate a container with web app
Weicheng SUN
sunweicheng0001 at gmail.com
Tue May 3 10:00:34 PDT 2016
Thanks a lot! I try that way, it actually can complete the restore
progress!
However, without doing bind(), the container's exposed port doesn't work.
I will keep on finding a way to solve it, do you have some idea?
Regards,
David Sun 孙炜程
School of Software Engineering, Shanghai Jiaotong University
Mobile: 15921638078
E-mail: SunWeicheng0001 at gmail.com
2016-05-04 0:25 GMT+08:00 Ross Boucher <rboucher at gmail.com>:
> I have not provided the modified CRIU in that release. This is a very
> hacky way to simply drop sockets you can try:
> https://github.com/boucher/criu/commit/0539fbc68228903ad4a2cae2b3737c6e888ab93d
>
>
> On Tue, May 3, 2016 at 12:19 PM Weicheng SUN <sunweicheng0001 at gmail.com>
> wrote:
>
>> Thankfully, You understand what I mean. I know that I should request a
>> same IP address and the CRIU I use is the release you give in cr-combined(I
>> guess this is the modified CRIU you mentioned).
>> The problem is I do not know how to request a container with specific IP
>> address via docker command or RESTful API. I know there is docker run --ip
>> for later than docker v1.10, but the latest release of cr-combined doesn't
>> support this flag.
>> I tried to modified the source code of docker v1.10, but it always hangs
>> on without any response while running, :(.
>> Do you know how to request such a container with the release version you
>> give?
>>
>> Regards,
>>
>> David Sun 孙炜程
>> School of Software Engineering, Shanghai Jiaotong University
>>
>> Mobile: 15921638078
>>
>> E-mail: SunWeicheng0001 at gmail.com
>>
>> 2016-05-04 0:09 GMT+08:00 Ross Boucher <rboucher at gmail.com>:
>>
>>> What we've done is modified the CRIU source to simply drop these
>>> unrestorable connections, rather than error out. Perhaps that could be
>>> turned into an option.
>>>
>>> On Tue, May 3, 2016 at 12:08 PM Ross Boucher <rboucher at gmail.com> wrote:
>>>
>>>> You should be able to request the same IP when creating the new docker
>>>> container. Similarly, you could do the same for any linked containers.
>>>>
>>>> On Tue, May 3, 2016 at 12:07 PM Weicheng SUN <sunweicheng0001 at gmail.com>
>>>> wrote:
>>>>
>>>>> I know what you mean. But I just want to migrate some containers to
>>>>> another host, all of those application can deal tcp reconnection.
>>>>> You say if there are some packets cannot deliver into new container's
>>>>> location, the restore will broken.
>>>>> So, If there is* a method to skip this progress, just to bind the old
>>>>> ip address to the container on the new host.*
>>>>> Everytime I checkpoint a container with tcp connection, scp to another
>>>>> host, then restore, the restore log always say that
>>>>>
>>>>> (00.294516) 1: Found id pipe:[6392267] (fd 1) in inherit fd list
>>>>> (00.294520) 1: File pipe:[6392267] will be restored from fd 3
>>>>> dumped from inherit fd 1
>>>>> (00.294535) 1: Found fd 1 (id pipe:[6392267]) in inherit fd list
>>>>> (caller inherit_fd_resolve_clash)
>>>>> (00.294538) 1: Inherit fd 1 moved to 3 to resolve clash
>>>>> (00.294541) 1: Create fd for 1
>>>>> (00.294544) 1: Restoring fd 2 (state -> create)
>>>>> (00.294545) 1: Creating pipe pipe_id=0x6189cc id=0x3
>>>>> (00.294547) 1: Found id pipe:[6392268] (fd 2) in inherit fd list
>>>>> (00.294548) 1: File pipe:[6392268] will be restored from fd 4
>>>>> dumped from inherit fd 2
>>>>> (00.294554) 1: Found fd 2 (id pipe:[6392268]) in inherit fd list
>>>>> (caller inherit_fd_resolve_clash)
>>>>> (00.294555) 1: Inherit fd 2 moved to 4 to resolve clash
>>>>> (00.294558) 1: Create fd for 2
>>>>> (00.294560) 1: Restoring fd 4 (state -> create)
>>>>> (00.294569) 1: Restore: family 10 type 1 proto 6 port 6379
>>>>> state 10 src_addr ::
>>>>> (00.294592) 1: 5 restore sndbuf 16384 rcv buf 87380
>>>>> (00.294595) 1: restore priority 0 for socket
>>>>> (00.294596) 1: restore rcvlowat 1 for socket
>>>>> (00.294598) 1: restore mark 0 for socket
>>>>> (00.294611) 1: Found fd 4 (id pipe:[6392268]) in inherit fd list
>>>>> (caller inherit_fd_resolve_clash)
>>>>> (00.294616) 1: Inherit fd 4 moved to 6 to resolve clash
>>>>> (00.294619) 1: Create fd for 4
>>>>> (00.294622) 1: Restoring fd 5 (state -> create)
>>>>> (00.294625) 1: Restore: family 2 type 1 proto 6 port 6379
>>>>> state 10 src_addr 0.0.0.0
>>>>> (00.294633) 1: 5 restore sndbuf 16384 rcv buf 87380
>>>>> (00.294635) 1: restore priority 0 for socket
>>>>> (00.294636) 1: restore rcvlowat 1 for socket
>>>>> (00.294638) 1: restore mark 0 for socket
>>>>> (00.294640) 1: Create fd for 5
>>>>> (00.294642) 1: Restoring fd 6 (state -> create)
>>>>> (00.294644) 1: Restore: family 2 type 1 proto 6 port 6379
>>>>> state 1 src_addr 172.17.128.2
>>>>> (00.294646) 1: Restoring TCP connection
>>>>> (00.294649) 1: Restoring TCP connection id 7 ino 619526
>>>>> (00.294657) 1: Setting 1 queue seq to 2786935679
>>>>> (00.294659) 1: Setting 2 queue seq to 919486667
>>>>> (00.294679) 1: Error (sk-inet.c:721): Can't bind inet socket (id
>>>>> 7): Cannot assign requested address
>>>>>
>>>>> You see, 172.17.128.2 is the old ip, criu tried to bind this ip to new
>>>>> container, but failed.
>>>>>
>>>>> Regards,
>>>>>
>>>>> David Sun 孙炜程
>>>>> School of Software Engineering, Shanghai Jiaotong University
>>>>>
>>>>> Mobile: 15921638078
>>>>>
>>>>> E-mail: SunWeicheng0001 at gmail.com
>>>>>
>>>>> 2016-04-28 18:33 GMT+08:00 Pavel Emelyanov <xemul at virtuozzo.com>:
>>>>>
>>>>>> On 04/28/2016 08:01 AM, Weicheng SUN wrote:
>>>>>> > Hi Everyone,
>>>>>> >
>>>>>> > The latest release of cr-combined said that it supports network.
>>>>>> Then I do some experiments. I use
>>>>>> > 1. docker run -d -v demo:/data --name=redis redis:latest
>>>>>> > 2. docker run -d -e USE_REDIS_HOST=redis --link redis:redis -p
>>>>>> 80:80 --name=app binocarlos/moby-counter:latest
>>>>>> > which is a demo of simple website and redis is its storage. I first
>>>>>> run them on host A
>>>>>> >
>>>>>> > I try to checkpoint them and copy to another host(host B). I create
>>>>>> two containers with same configuration
>>>>>> > of them and applied the change of file system to the new created
>>>>>> container. Then I tried to restore them,
>>>>>> > which sometimes came out a wrong result.
>>>>>> > I notice that when redis and app have same ip address on host A and
>>>>>> B, then the restore will success. But,
>>>>>> > when they have different IP on two hosts, the restore progress will
>>>>>> certainly broken.
>>>>>> >
>>>>>> > The reason I guess is that the state of tcp connection in
>>>>>> checkpoint image didn't match the new environment
>>>>>> > in host B. For example, redis in host A is 17.172.20.1 and app in
>>>>>> host A is 17.172.20.2, then for app there
>>>>>> > is a connection whose remote host is 17.172.20.1. Then come to host
>>>>>> B, if redis in host B is 17.172.20.3 and
>>>>>> > when I try to restore app, criu will confuse where is
>>>>>> 17.172.20.1(redis)?
>>>>>>
>>>>>> After migration all the sockets get restored with the IP addresses
>>>>>> they had on source node,
>>>>>> so if for some reason packets to former container IP cannot be
>>>>>> delivered into container's
>>>>>> new location, the container would get broken. This is unavoidable
>>>>>> limitation of TCP protocol
>>>>>> itself. There can be workarounds to this (DNAT-like for example), but
>>>>>> this is out of CRIU's
>>>>>> scope and should be done on Docker level.
>>>>>>
>>>>>> > Generally, is there always a problem to checkpoint and restore a
>>>>>> container, who has a link with other
>>>>>> > containers, on the another host?
>>>>>> >
>>>>>> > And who knows that how to use a specific IP address while start a
>>>>>> new container? For the latest release of
>>>>>> > cr-combined doesn't support docker run --ip. Even --ip is
>>>>>> supported, it requires a user defined network,
>>>>>> > default network is not supported.
>>>>>> >
>>>>>> > Hopes for your kindly response & wish all of you a great day!
>>>>>> >
>>>>>> > Regards,
>>>>>> >
>>>>>> > David Sun
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > 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/20160504/03c043e6/attachment.html>
More information about the CRIU
mailing list