Thanks Konstantin! Jake
On Thu, Apr 21, 2016 at 2:53 AM, Konstantin Khorenko <khore...@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 >> <khore...@virtuozzo.com> wrote: >>> >>> -------- Forwarded Message -------- >>> Subject: [TRD] Autofs migration >>> Date: Tue, 19 Apr 2016 11:03:17 +0200 >>> From: Stanislav Kinsburskiy <skinsbur...@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 >>> >>> skinsbur...@virtuozzo.com >>> _______________________________________________ >>> Users mailing list >>> Users@openvz.org >>> https://lists.openvz.org/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users@openvz.org >> https://lists.openvz.org/mailman/listinfo/users >> . >> > _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users