A network device, which is connected to a bridge, is restored
after the bridge. In this case we can set the master attribute and
the device will be connected to the bridge automatically.
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
It is possible to assign id for network namespaces and
this id will be used by the kernel in some netlink messages.
If no id is assigned when the kernel needs it, it will be
automatically assigned by the kernel.
For example, this id is reported for peer veth devices.
v2: add a comment
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
Nothing special here, just parse all known NLAs and keep them
on the image.
Issue #11
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
venet is not virtuozzo specific but rather
came from openvz, make it so.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrei Vagin <avagin@virtuozzo.com>
While this is in principle similar to how veths are handled, we have to do
things in two different ways depending on whether or not there is a user
namespace involved, because there is no way to ask the kernel to attach a
macvlan NIC to a device in a net ns that we don't have CAP_NET_ADMIN in.
So we do it in two ways:
a. If we are in a user namespace, we create the device in usernsd and use
IFLA_NET_NS_FD to set the netns which it should be created in (saving
us a "move into this netns" step).
b. If we aren't in a user namespace, we could still be in a net namespace,
so we use IFLA_LINK_NETNSID to set namespace that the i/o device will be
in. Then we open a netlink socket from criu's netns and use
IFLA_NET_NS_FD to tell the kernel to create the macvlan device in the
target's namespace.
v2: * s/CLONE_NEWNET/CLONE_NEWUSER
* Don't bother to dump IFLA_LINK and IFLA_LINK_NETNSID. Although we
need to provide these on restore, there's no kernel interface that
persists these. To populate IFLA_LINK, we require users pass
--macvlan-pair, and we create a NETNSID relation as needed and pass
that in for macvlan links (although this infrastructure could be used
elsewhere for links that need it in the future, since is in the
hoisted populate_newlink_req()).
* use new external command instead of creating a --macvlan-pair option
v3: add a feature check for linux/net_namespace.h, since not every arch in
travis has this (new-ish) header
v4: * include sys/types.h instead of linux/if.h to get IFF_UP flag
* remove old doc addition about --macvlan-pair option
v5: define IFLA_LINK_NETNSID and RTM_NEWNSID if they don't exist
v6: define IFLA_MACVLAN_FLAGS and bump the size of IFLA_MACVLAN_MAX when
necessary
v7: * remove unused struct macvlan_pair
* split feature test for linux/net_namespace.h into separate patch
* move IFLA_INFO_MAX testing in dump_one_netdev to the right patch
* add documents for netwlink_extras fields
* split changeflags into separate patch
* use existing netnsid if we get EEXIST
* move macvlan code to a helper function
* use netnsid to restore in userns case, and not pid
v8: * define RTM_GETNSID since we use that too now :)
* don't bother with IFLA_MACVLAN_MAX; we only understand things up to
IFLA_MACVLAN_FLAGS, so let's just use that as our max instead. The
problem with using macros here, is that IFLA_MACLAN_MAX is defined as
a macro with an enum expansion in it, so we get bitten by the enum
not being available at preprocessing time, and implicit zero coercion
when testing against its value for stuff. Yeesh.
v10: * add some comments about when we set up NET_NS_FD and why we use
IFLA_LINK and IFLA_NET_NS_ID
* use the socket opened in restore_links() instead of opening one in
restore_one_macvlan()
* split the new argument to restore_one_link into its own patch
travis-ci: success for series starting with [v10,01/11] net: pass the struct nlattrs to dump() functions
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Reviewed-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
int32 with boolean value in protobuf has the same size with bool,
many sysctls are boolean but we don't lose anything by storing them
in int32, so add only int32 and string fields
will need string field for stable_secret ipv6 sysctl
also such fromat allows us to easily handle non-present int sysctls
we can check if we have it using has_*arg
v3: rebase images/Makefile to criu-dev branch
v4: use enum for type
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Reviewed-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
But keep @protobuf as a symlink: we have
this path encoded in sources. Gonna be
removed with time.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
