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
