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
