[CRIU] [PATCH] mount: rework perparation for pivot_root

Tycho Andersen tycho.andersen at canonical.com
Thu Sep 4 08:52:12 PDT 2014


On Thu, Sep 04, 2014 at 07:13:32PM +0400, Pavel Emelyanov wrote:
> On 09/04/2014 06:16 PM, Tycho Andersen wrote:
> > Hi Pavel,
> > 
> > On Thu, Sep 04, 2014 at 03:24:15PM +0400, Pavel Emelyanov wrote:
> >> On 09/04/2014 01:51 AM, Saied Kazemi wrote:
> >>> FWIW, here is what I've been doing for Docker:
> >>>
> >>> - If the filesystem is AUFS or UnionFS, it definitely has to be created by an "agent" before attempting to restore.  The right agent would be Docker.  But until native C/R is added to Docker, we can use a helper script to set up the filesystem.  This is actually done by the docker_cr.sh script that I sent earlier.  Once created, it exists in /proc/mounts and restore is successful.
> >>>
> >>> - If the filesystem is VFS, it doesn't have to be set up but it has to be bind mounted onto itself for restore to succeed.  This can be done by CRIU itself either automatically or via a command line option.  Currently, it's done in the helper script before restore.
> >>>
> >>> I haven't experimented with LXC or other configurations.
> >>
> >> I have one more concern about user-namespaces. AFAIU if LXC/Docker would prepare root while
> >> sitting in the user-ns, the resulting mountpoint would be "tagged" with the new userns.
> > 
> > Right now the lxc-restore code doesn't prepare the mountpoint in the
> > container's userns, although perhaps it should (?).
> > 
> >> In that case, CRIU will _have_ to prepare the root mountpoint _inside_ this userns too. But
> >> since CRIU doesn't know how to prepare root, we probably need some "generic" way of doing
> >> this.
> > 
> > I was thinking that we would prepare (mount, in the case of a block
> > device, but a no-op in the case of just a directory) the rootfs and
> > then pass it to criu via --root. criu would then do whatever it needs
> > to do, e.g. with Andrey's patch in this thread it bind mounts the dir
> > to itself for pivot_root (and ultimately userns support, although I
> > don't exactly understand how that works).
> > 
> > I guess for userns support we need to do the prepare step inside the
> > userns, not just the bind mount step?
> 
> Yup. Exactly, CRIU should prepare root after starting new userns. But since we
> shouldn't encode any ways of preparing root inside CRIU, we have a kind of
> chicken and egg problem :)

I see. Another script, then?

Tycho


More information about the CRIU mailing list