[Devel] [TRD] Autofs migration

[Konstantin Khorenko]

Disclaimer: not sending this into users at openvz.org because external jira issue has not been created due to unknown reason.

One more known issue:
* "browse" autofs config option is not supported

https://jira.sw.ru/browse/PSBM-48659

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 04/19/2016 12:03 PM, Stanislav Kinsburskiy wrote:
> 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
>
> .
>