[CRIU] Debugging the process to restore veth in a namespace

[Hui Kang]

Thanks for clarifying this. This makes sense to me.

Before I write my own post-restore script, does criu have such script
included?

- Hui

On Sun, Aug 16, 2015 at 9:23 PM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> On 08/16/2015 10:12 PM, Hui Kang wrote:
> > Hi, Pavel
> > I used "--veth-pair veth101=veth100" when dumping and restoring a
> process. veth101 is the
> > device name in the process net namespace, veth100 is the other end which
> is in the criu host.
> >
> > After restore, I can see the ip address of veth101 is restored. However,
> the veth end in the
> > host (veth100) is not successfully restored. By "not success", I mean
> the veth100 link is
> > created, however, its state is DOWN and no IP is assigned to the restore
> link. Only I manually
> > set the link state to UP and assigne IP, the two ends can talk to each
> other.
>
> Yup, this is the host-side of the link. CRIU only manages the container
> side. If you need
> to do some configuration of the host-side part before the resume, you can
> hook in to the
> post-restore action script.
>
> > Moreover, the link index of veth100 is not the same as when I dump the
> process. For example
> > the index for veth101 and veth100 is 15 and 16 when I dump the process.
> After restore,
> > veth100's index becomes 17. Is this a bug in CRIU? Thanks.
>
> No, it's not a bug. The problem is that when you do the host-side link
> restore the index
> of it can be busy, so we don't even try to preserve it. Even if we do the
> "best-effort"
> attempt, it will succeed only in trivial cases.
>
> -- Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150816/ee11a402/attachment.html>