[Users] [TRD] Autofs migration

[jjs - mainphrame]

Hi Konstantin -

In the process of taking a look at this, I found that jira.sw.ru does
not resolve. DNS problem on the sw.ru side?

Regards,

Jake

On Tue, Apr 19, 2016 at 3:41 AM, Konstantin Khorenko
<khorenko at virtuozzo.com> wrote:
> -------- Forwarded Message --------
> Subject: [TRD] Autofs migration
> Date: Tue, 19 Apr 2016 11:03:17 +0200
> From: Stanislav Kinsburskiy <skinsbursky at virtuozzo.com>
>
>
> 1. Feature
>
> Autofs mount points migration via CRIU
> https://jira.sw.ru/browse/PSBM-41217
>
> 2. Description
>
> CRIU now supports autofs file system migration, including direct,
> indirect and offset mount types.
>
> 3. Products
>
> Virtuozzo 7
>
> Packages:
>      criu-2.1.0.4.vz7
>      libvzctl-7.0.199
>
> 4. Testing
>
> 4.1 Basics
>      ** Install criu and libvzctl rpm packages
>      ** Create a container, and check
>      ** Check, that autofs is listed in /proc/filesystems in the container
>      ** Check, that /dev/autofs is accessible
>      ** Install autofs package inside the container
>      ** Follow autofs guide to create an autofs _direct_ mount point
> with some file system, mounted on top (tmpfs, for example). Command "man
> autofs" might help
>      ** Follow autofs guide to create an autofs _indirect_ mount point
> with some file system, mounted on top (tmpfs, for example).
>   ** Follow autofs guide to create an autofs _offset_ mount point with
> some file system, mounted on top (tmpfs, for example).
>      ** Suspend and restore container
>      ** Check, that autofs mounts and nested were mounts migrated
> successfully (via /proc, for example).
>
> 4.2 Systemd autofs services
>      ** Start any systemds autofs service (for example,
> proc-sys-fs-binfmt_misc.automount) in the container
>      ** Check, that service started successfully
>      ** Suspend and restore container
>      ** Check, that autofs and nested mount points were migrated
> successfully.
>      ** Check, that systemd service has active status
>      ** Unmount nested file system manually
>      ** Access systemd autofs mount point and check, that nested file
> system is re-mounted again
>
> 4.3 Automount expiration
>      ** setup autofs mount  with short timeout (10 seconds, for example)
> in a container via any master: automount, systemd or else
>      ** Activate autofs mount point (nested mount point should be
> mounted by autofs master)
>      ** Migrate (or suspend/resume) the container.
>      ** Check, that nested mount point is unmounted after restore within
> timeout.
>
> 5. Known issues
>
> Autofs migration has an issue, related to systemd-controlled autofs
> mount points. Systemd saves autofs mount point device number in it's
> internals and compare this number to actual one, taken  from mount
> point, on each autofs request from kernel (mount, umount, expire, etc).
> The problem is that after migration all mount points are created
> manually and has _another_ device id, which leads to ignorance of kernel
> requests from systemd side.
> This problem can't be solved without some kind of "device namespaces"
> abstraction. However, some of the systemd services like
> proc-sys-fs-binfmt_misc.automount can be painlessly restarted after
> restore, thus illuminating this issue.
> Restart of proc-sys-fs-binfmt_misc.automount service is done by CRIU via
> action script, provided by vzctl.
>
> 6. What was checked by developer
>
> Both 4.1 and 4.2 test sequences
>
> 7. Feature owners
>
> skinsbursky at virtuozzo.com
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users