diff options
author | Tycho Andersen <tycho.andersen@canonical.com> | 2016-10-20 19:25:28 +0300 |
---|---|---|
committer | Pavel Emelyanov <xemul@virtuozzo.com> | 2016-11-03 18:14:17 +0300 |
commit | 5f2233ea717f3f68e158cf4c54bb51b58802176e (patch) | |
tree | 2c087cbe636e9954f5460f148e1d505069f9b032 /images/macvlan.proto | |
parent | aff66b4e18938a4cce71abddde4df33ce6af3f68 (diff) |
net: add support for macvlan link types
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>
Diffstat (limited to 'images/macvlan.proto')
-rw-r--r-- | images/macvlan.proto | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/images/macvlan.proto b/images/macvlan.proto new file mode 100644 index 000000000..c9c90458e --- /dev/null +++ b/images/macvlan.proto @@ -0,0 +1,4 @@ +message macvlan_link_entry { + required uint32 mode = 1; + optional uint32 flags = 2; +} |