When live migrating a container with large amount of processes
inside the time to do page-server-ed dump may be up to 10 times
slower than for the local dump.
The delay is always introduced in the open_page_server_xfer()
when criu negotiates the has_parent bit on the 2nd task. This
likely happens because of the Nagel algo taking place -- after
the write() of the OPEN2 command happened kernel delays this
command sending waiting for more data.
v2:
Fix this by turning on CORK option on memory transfer sockets
on send side, and NODELAY one once on urgent data. Receive
side is always NODELAY-ed. According to Alexey Kuznetsov this
is the best mode ever for such type of transfers.
v3:
Push packets in pre-dump's check_parent_server_xfer too.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Andrew Vagin <avagin@odin.com>
Conflicts:
include/util.h
util.c
This values will be doubled in kernel to account for
"struct sk_buff" etc. overhead.
Currently criu restores snd and rcv buffer limits incorrectly,
they become bigger on each iteration.
$ ../crit show dump/zdtm/live/static/socket-tcp/6299/1/inetsk.img | grep buf
"so_sndbuf": 2626560,
"so_rcvbuf": 1060720,
"so_sndbuf": 16384,
"so_rcvbuf": 87380,
$ ../crit show dump/zdtm/live/static/socket-tcp/6299/2/inetsk.img | grep buf
"so_sndbuf": 5253120,
"so_rcvbuf": 2121440,
"so_sndbuf": 32768,
"so_rcvbuf": 174760,
$ ../crit show dump/zdtm/live/static/socket-tcp/6299/3/inetsk.img | grep buf
"so_sndbuf": 10506240,
"so_rcvbuf": 4242880,
"so_sndbuf": 65536,
"so_rcvbuf": 349520,
With-help-of: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When restoring venet device we need to restore its
index as well, which actually possible with new iproute2
package but the problem is that the index itself lays
inside image file. We could use crit tool to extract
it but this would slowdon procedure signifantly (need
to run python which would parse the image, or need
to pass the index into environmnet from inside of
the CRIU itself).
So lets do a trick and simply created venet device
inside container by criu itself (thanks we support
creating venet via netlink interface now).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@odin.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Name with up to UNIX_PATH_MAX in length is
allowed value.
Reported-by: Nikita Spiridonov <nspiridonov@odin.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When we restore sockets with relative names we change
current working directory into the one provided by
socket image data. This actually affects current
criu state because the rest of code doesn't know
about such tricks and may rely on working dir
consistency.
So remember the current working dir and restore it
back once socket cwd operations are complete.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
OpenVZ creates per-container kernel threads and they live in
container's cgroups. CRIU should skip these threads, it's impossiable to
get any state of them.
Signed-off-by: Andrew Vagin <avagin@virtuozzo.org>
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If criu restore failed, criu should wait all processes because they
hold files, namespaces and other stuff that caller might want to
have released (in our case it was ploop device).
Here we do this only for cases when processes are restored in a pid
namespace. We'd like to do the same for non-ns case, but there's
no simple way to wait for a bunch of unconnected processes.
Another good side effect is that "Restoring FAILED." will be printed
at the end of the log (now after we kill init tasks still have time
to do smth and write log messages).
Cc: Nikita Spiridonov <nspiridonov@odin.com>
Reported-by: Nikita Spiridonov <nspiridonov@odin.com>
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In debian-8 container we faced the problem -- systemd creates nested
mount namespaces and inotify watchee are resolved into a path which
is inaccessbile on restore, the same happens when pathes where
watchees are living are bind-overmounted. Thus when we try to
restore such watchees we can't open the paths.
Lets do a trick here (thanks a huge to Andrew Vagin for idea and
overall help) -- walk over all mount points which device match
the handle's device and open handle first and test if the path
provided is openable as well for tmpfs and devtmps which do not
save inodes between remounts. After all the inotify objects are
bound to inode so it's irrelevean via which path it's assigned.
https://jira.sw.ru/browse/PSBM-39957
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
open_mountpoint helper is called when mount namespace are
already restored so we have to use local paths.
This is a continuation to patch a082f27b -- we keep mount
point id in fsnotify, thus we should use the namespace's
path for open.
https://jira.sw.ru/browse/PSBM-39957
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Otherwise it's impossible to understand from which namespace
this path should be opened.
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
For slave mount we need to make sure that all childrent
mountpoints of the master peer is mounted before we can
proceed otherwise there gonna be duplicated mountpoints
after the restore.
https://jira.sw.ru/browse/PSBM-39957
Signed-off-by: Andrew Vagin <avagin@odin.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Namespace roots might be slave ones from another
namespace roots, so we should not treat them as
"always ready" for mounting but rely on general
logic in can_mount_now which tests slaves relations.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When we initialize a sub-mount namespace, we need to use absolute paths.
For example we change cwd in prep_unix_sk_cwd()
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We have quite a lot of new stuff this time. More flexibility
in cgroup management code (and this story far from being over)
in the library and in the crit command line, preparations to
x66 32bit, that also helped the PPC port, freezer cgroup
filannly found its place in the code. We also had our first
CVE-s found :) and a LOT of bugs fixed.
So the plan for the 1.8 is: cgroups, secured containers and
bugfixes. x86 32bit is tempting too.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Travis testing engine complained about @_BSD_SOURCE
which is not the case on my build environment.
Anyway lets do a safe thing -- conditional definition.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
BTRFS uses own device numbering scheme so lets do a trick
close one to what we have in CRIU itself -- mangle
device to match mountinfo output.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@odin.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In particular we have to find out if we're
running on btrfs filesystem for proper device
number mangling.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Andrew Vagin <avagin@odin.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently the buffer size is 4096. It always works because
we use hosts where PAGE_SIZE is 4096. PowerPC64 has a bigger PAGE_SIZE.
Here is a comment from the kernel code.
/*
* skb should fit one page. This choice is good for headerless malloc.
* But we should limit to 8K so that userspace does not have to
* use enormous buffer sizes on recvmsg() calls just to avoid
* MSG_TRUNC when PAGE_SIZE is very large.
*/
We set the buffer size to 16384, because it's the max length of recvmsg()
for this case. We will need less iterations to collect all data, so
the perfomance should be better.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It lookups over shared entries and finds widest.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
- make sure it doesn't exist using O_EXCL
- don't forget to close it
Reported-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
1) Deleted bindmount for files should be restored
by creating temp file. The kernel doesn't permit
to mix bindmount in terms of file/dir relationship:
either both source and target should be files or
directories.
Thus we can call stat on the target and figure out
what kind of source we had.
2) Even for deleted entries better to use permissions
from the target's stat call, this makes result close
to how would it look if program hadn't been checkpointed.
Reported-by: Andrey Wagin <avagin@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The commit 69d008d567 ("Use run-time page_size() for mremap")
introduces the use of dynamic page size in rst-malloc.c.
The commit also add the include of unistd.h in
arch/aarch64/include/asm/page.h to allow the build to succeed on this
architecture. Since ppc64 is also using the same way to deal with page
size, the same include is required in arch/ppc64/include/asm/page.h
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
CC: Christopher Covington <cov@codeaurora.org>
Reviewed-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
To handle deleted bindmounts we simply create
the former directory bindmount lived at, mount
the target and remove the directory back.
For this sake we add @deleted entry into the image.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Make it handle both postfixes and return
non-zero code if stipping happened.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
