From: Cyrill Gorcunov <gorcu...@virtuozzo.com>
When doing checpoint/restore during migration we use netlink
sockets with diag functionality to fetch various information
we need. In particular when restoring on the machine where
say netfilter modules are not loaded we fail with
| [root@s175 ~]# less /vz/dump/rst-iVS9OC-16.05.04-22.32/criu_restore.11.log
| (00.151066) 1: Running ip addr restore
| RTNETLINK answers: File exists
| RTNETLINK answers: File exists
| (00.152641) 1: Running ip route restore
| (00.175144) 1: Running ip route restore
| (00.184676) 1: Running ip rule delete
| (00.186448) 1: Running ip rule delete
| (00.188191) 1: Running ip rule delete
| (00.190054) 1: Running ip rule restore
| (00.191964) 1: Running iptables-restore for iptables-restore
| (00.200958) 1: Running ip6tables-restore for ip6tables-restore
| >(00.203833) 1: Error (net.c:466): Can't open rtnl sock for net dump:
Protocol not supported
| (00.229107) Error (cr-restore.c:1407): 15091 killed by signal 9: Killed
| (00.229192) Switching to new ns to clean ghosts
| (00.241142) uns: calling exit_usernsd (-1, 1)
| (00.241173) uns: daemon calls 0x454950 (15085, -1, 1)
| (00.241188) uns: `- daemon exits w/ 0
| (00.241570) uns: daemon stopped
| (00.241584) Error (cr-restore.c:2248): Restoring FAILED
which stands for the following criu code
| sk = socket(AF_NETLINK, SOCK_RAW, NETLINK_NETFILTER);
| if (sk < 0) {
| pr_perror("Can't open rtnl sock for net dump");
| goto out_img;
| }
because the nfnetlink module is not loaded on the destination machine
we're failing. If we would have been running on node the module would
be uploaded automatically but restore happens in veX context where modules
can't be uploaded.
Thus add modules needed for c/r into whitelist, so the criu will
upload them automatically.
https://jira.sw.ru/browse/PSBM-46789
CC: Vladimir Davydov <vdavy...@virtuozzo.com>
CC: Konstantin Khorenko <khore...@virtuozzo.com>
CC: Andrey Vagin <ava...@openvz.org>
CC: Pavel Emelyanov <xe...@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcu...@virtuozzo.com>
+++
ve/kmod: Change modules whitelist to fit their aliases
When we do call for specifed sockets such as netlink netfilter,
dialog sockets and such we imply that the kernel will autoload
them. But previously (e0914131eeb08e6b1953c682be05b9fbcf185f1f
"ve/kmod: Add modules to whitelist for c/r sake")
I put module names instead of their alises used in net subsystem
to determinate which module to load on socket/protocol types.
Fix it putting proper names here.
Thanks to Vladimir to point the problem.
https://jira.sw.ru/browse/PSBM-46789
CC: Konstantin Khorenko <khore...@virtuozzo.com>
CC: Andrey Vagin <ava...@openvz.org>
CC: Pavel Emelyanov <xe...@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcu...@virtuozzo.com>
Reviewed-by: Vladimir Davydov <vdavy...@virtuozzo.com>
+++
ve/kmod: Allow netfilter conntrack inside VE
Netfilter conntrack module is used during checkpoint (which
is done on node) so the modules get autoloaded but in case
of migration the restore starts inside veX so we need to allow
the conntrack to be requested from ve context. Thus add them
into whitelist.
Initially missed them in ebc70d73717f592c89ad992f77587d9e118bbee6.
https://jira.sw.ru/browse/PSBM-47359
CC: Vladimir Davydov <vdavy...@virtuozzo.com>
CC: Konstantin Khorenko <khore...@virtuozzo.com>
CC: Andrey Vagin <ava...@openvz.org>
CC: Pavel Emelyanov <xe...@virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcu...@virtuozzo.com>
https://jira.sw.ru/browse/PSBM-127787
(cherry picked from vz7 commit 7d9c655b08b4397fc04430540fdbc763e56beacb)
Signed-off-by: Konstantin Khorenko <khore...@virtuozzo.com>
---
kernel/kmod.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/kernel/kmod.c b/kernel/kmod.c
index b8ca90bec921..36420d60cce2 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -234,6 +234,31 @@ static const char * const ve0_allowed_mod[] = {
"fs-binfmt_misc",
"fs-overlay",
+
+ /* inet_diag, inet6_diag */
+ "net-pf-16-proto-4-type-2", /* PF_NETLINK, NETLINK_SOCK_DIAG,
AF_INET */
+ "net-pf-16-proto-4-type-10", /* PF_NETLINK, NETLINK_SOCK_DIAG,
AF_INET6 */
+
+ /* tcp_diag */
+ "net-pf-16-proto-4-type-2-6", /* PF_NETLINK, NETLINK_SOCK_DIAG,
AF_INET - IPPROTO_TCP */
+
+ /* udp_diag */
+ "net-pf-16-proto-4-type-2-17", /* PF_NETLINK, NETLINK_SOCK_DIAG,
AF_INET - IPPROTO_UDP */
+ "net-pf-16-proto-4-type-2-136", /* PF_NETLINK, NETLINK_SOCK_DIAG,
AF_INET - IPPROTO_UDPLITE */
+
+ /* nfnetlink */
+ "net-pf-16-proto-12", /* PF_NETLINK, NETLINK_NETFILTER */
+ "nfnetlink-subsys-1", /* NFNL_SUBSYS_CTNETLINK */
+ "nfnetlink-subsys-2", /* NFNL_SUBSYS_CTNETLINK_EXP */
+
+ /* unix_diag */
+ "net-pf-16-proto-4-type-1", /* PF_NETLINK, NETLINK_SOCK_DIAG,
AF_LOCAL */
+
+ /* af_packet_diag */
+ "net-pf-16-proto-4-type-17", /* PF_NETLINK, NETLINK_SOCK_DIAG,
AF_PACKET */
+
+ /* netlink_diag */
+ "net-pf-16-proto-4-type-16", /* PF_NETLINK, NETLINK_SOCK_DIAG,
AF_NETLINK */
};
/*
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
