[Users] [TRD] Autofs migration

[Konstantin Khorenko]

Hi Jake,

nope, it's not a DNS problem, it's just an link to the internal jira issue,
sorry for that.

The proper link is: https://bugs.openvz.org/browse/OVZ-6719

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 04/20/2016 12:59 AM, jjs - mainphrame wrote:
> 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
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
> .
>