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

[Pavel Emelyanov]

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 :)

> Thanks,
> 
> TYcho
> 
>> Thoughts?
>>
>>> --Saied
>>>
>>>
>>>
>>>
>>> On Wed, Sep 3, 2014 at 2:23 PM, Tycho Andersen <tycho.andersen at canonical.com <mailto:tycho.andersen at canonical.com>> wrote:
>>>
>>>     Hi Pavel,
>>>
>>>     On Wed, Sep 03, 2014 at 08:43:13PM +0400, Pavel Emelyanov wrote:
>>>     > On 08/08/2014 04:18 PM, Andrey Vagin wrote:
>>>     > > We can't bind-mount the required root into itself instead of
>>>     > > resolving a parent mount.
>>>     > >
>>>     > > This patch is required to support userns, because if we want to make
>>>     > > pivot_root, the parent mount can't be locked. When we create userns
>>>     > > and mntns, all inherited mounts are marked as locked.
>>>     > >
>>>     > > Cc: Tycho Andersen <tycho.andersen at canonical.com <mailto:tycho.andersen at canonical.com>>
>>>     > > Signed-off-by: Andrey Vagin <avagin at openvz.org <mailto:avagin at openvz.org>>
>>>     >
>>>     > Andrey, Tycho,
>>>     >
>>>     > AFAIU we haven't yet decided what to do with the root mountpoint
>>>     > preparation. Am I right? Can we resurrect the discussion if it's
>>>     > still relevant?
>>>
>>>     The issue that caused this patch was actually my misunderstanding,
>>>     Andrew and I talked about it on IRC. I'm not sure (other than applying
>>>     this patch, which is a usability improvement at least) that criu can
>>>     do anything to prepare the rootfs. In the case of LXC it could be a
>>>     block device or something, which I guess criu doesn't know how to set
>>>     up?
>>>
>>>     Anyway, I think it is ok to expect users to set up their own rootfs,
>>>     unless there is some nice way we could do it.
>>>
>>>     Tycho
>>>
>>>     > Thanks,
>>>     > Pavel
>>>     >
>>>     _______________________________________________
>>>     CRIU mailing list
>>>     CRIU at openvz.org <mailto:CRIU at openvz.org>
>>>     https://lists.openvz.org/mailman/listinfo/criu
>>>
>>>
>>
> .
>