[Users] [TRD] Autofs migration

jjs - mainphrame jjs at mainphrame.com
Thu Apr 21 09:21:27 PDT 2016


Thanks Konstantin!

Jake

On Thu, Apr 21, 2016 at 2:53 AM, Konstantin Khorenko
<khorenko at virtuozzo.com> wrote:
> 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
>> .
>>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users


More information about the Users mailing list