[CRIU] [P.haul + Docker] Missing Running States During Live Migration of Container
Pavel Emelyanov
xemul at virtuozzo.com
Tue Feb 28 07:13:43 PST 2017
On 02/22/2017 10:16 PM, Ross Boucher wrote:
> My branch contains just a few minor changes from what was already there, mostly changes to hard coded
> values. I don't really remember exactly how the process works, but I think the only "solution" to the
> race problem is going to be to pause the container before performing the checkpoint and filesystem
> operations, and then unpausing on resume. I'm not sure if the CRIU bug with not being able to checkpoint
> frozen processes still exists, but I also know that Docker doesn't currently support the incremental
> checkpointing stuff, so this solution may be somewhat slow in real world use (though, maybe p.haul isn't
> actually using `docker checkpoint`?)
It doesn't :( The newer plan, actually, is to drive go phaul to working state
and make "native" live migration in Docker using this go code.
-- Pavel
> On Wed, Feb 22, 2017 at 2:49 AM Pavel Emelyanov <xemul at virtuozzo.com <mailto:xemul at virtuozzo.com>> wrote:
>
> On 02/20/2017 10:47 PM, Lele Ma wrote:
> > On Mon, Feb 20, 2017 at 2:37 PM, Pavel Emelyanov <xemul at virtuozzo.com <mailto:xemul at virtuozzo.com>> wrote:
> >> On 02/20/2017 10:23 PM, Lele Ma wrote:
> >>>
> >>> On Mon, Feb 20, 2017 at 1:16 PM, Pavel Emelyanov <xemul at virtuozzo.com <mailto:xemul at virtuozzo.com> <mailto:xemul at virtuozzo.com <mailto:xemul at virtuozzo.com>>> wrote:
> >>>
> >>> On 02/19/2017 10:50 PM, Lele Ma wrote:
> >>> > Hi All,
> >>> >
> >>> > I am testing container live migration with this github repos <https://github.com/boucher/docker/tree/v1.10_2-16-16-experimental <https://github.com/boucher/docker/tree/v1.10_2-16-16-experimental>> for docker-1.10-dev. I found the container not restored exactly where it's checkpointed. For example:
> >>> >
> >>> > The container I run
> >>> > docker run -d busybox /bin/sh -c 'echo > /foo; max=1000000; i=0; while [ $i -lt $max ] ; do date >> /foo; date +%s >> /foo; echo "i=$i" >> /foo; i=$(expr $i + 1 ); sleep 0.0001; done'
> >>> >
> >>> > After migrated using p.haul, I got the /foo in target node:
> >>> > .....
> >>> > Sun Feb 19 03:23:13 UTC 2017
> >>> > 1487474593
> >>> > i=4247
> >>> > Sun Feb 19 03:23:13 UTC 2017
> >>> > 1487474593
> >>> > i=4248 -----> before migration
> >>> > i=7545 -----> after migartion ( it is supposed to be i=4249 )
> >>> > Sun Feb 19 03:23:20 UTC 2017
> >>> > 1487474600
> >>> > i=7546
> >>> > Sun Feb 19 03:23:20 UTC 2017
> >>> > 1487474600
> >>> > i=7547
> >>> > ......
> >>> > The printed numbers jump from 'i=4248' to 'i=7545' instead of increasing by one. It seems that it ignores
> >>> > some computation status of the docker containers. But I am not sure where it goes wrong. However, when I
> >>> > checkpoint and restore the container locally, the number increase continuously with no such jumping.
> >>>
> >>> Where do you get these numbers from? Docker console or some file on disk?
> >>>
> >>>
> >>> It's from the file '/foo' inside container. ( The container is running /bin/sh -c 'echo > /foo;
> >>> max=1000000; i=0; while [ $i -lt $max ] ; do date >> /foo; date +%s >> /foo; echo "i=$i" >> /foo;
> >>> i=$(expr $i + 1 ); sleep 0.0001; done' )
> >>
> >> Then this is likely a race between images sync and filesystem sync.
> >> You can check your /foo file on the source node right after container
> >> migration, it should contain the missing numbers :)
> >>
> >> What p.haul do you use, btw?
> >
> > Thank you. But how can we avoid the race?
>
> Somewhere the final rsync is missing. But it's just a guess, I'd suggest
> that we first check whether it's really the case. Can you check the /foo
> files on both source and destination nodes?
>
> > I am using this repo from
> > Ross Boucher: https://github.com/boucher/p.haul/tree/docker-1.10
>
> Ah :) That's Ross' fork. Let's ask Ross to join us in this discussion.
>
> -- Pavel
>
More information about the CRIU
mailing list