Re: RFC: Network namespaces in NM

On Thu, 2016-02-04 at 12:21 +0100, Stjepan Groš wrote:

Is anyone working on network namespaces support in NetworkManager? Or
was thinking what is a "proper way" of implementing them?

Nobody is currently working on that. Great that you pick it up. You did
already an impressive amount of work!

I'm experimenting with adding support to NM and what I implemented so
far is:

1. Added objects NMNetnsController which would control all network
namespaces managed by NM.

2. Each network namespace is represented with an object NMNetns and
exposed on DBus. There are no methods so far but only a property name
which contains network namespace's name on the filesystem.

3. NMNetnsController exposes object NetworkNamespacesController with
methods AddNetworkNamepace and ListNetworkNamespaces. The first one
take a name as an argument and creates a new (iproute2 compatible)
network namespace, while the second one provides a list of existing

4. When new network namespace is created (using  AddNetworkNamepace
method) a new, private, platform layer is instantiated and loopback
interface within namespace activated. Note that new platform layer
has to be created because once a socket is opened in one network
namespace it is bound to the given namespace no matter which
namespace is active so current singleton object wouldn't work without
heavy refactoring!

What I intend to do next is:

1. NM has to monitor devices/IP addresses in new network namespaces

2. Methods that would allow an IPv4 or IPv6 address to be assigned in
some network namespace.

All the code is here:

and since this is PoC, there are A LOT OF BUGS AND MISSING FEATURES.

So, what do you think? Any comments, suggestions, critiques, etc?

This was on the future todo list, but at this point it's not yet fully
clear what is the purpose of netns support in NM should be.

I could imagine:

  - exposing runtime configuration about existing netns on the D-Bus 
  - possibly including the devices and IP address configuration on
    each of these namespaces
  - possibly creating new namespaces
  - possibly an "ip netns exec" counterpart?

The above is relatively easy.

One thing to consider is that potentially a huge number of netns exists
(e.g. spawning many containers). So, we must be careful not to do too
For example, NM uses D-Bus ObjectManager, meaning that (even if there
are no users interested in those namespaces), the D-Bus API will
already construct the whole object tree.
Preferably objects are created on demand so you don't pay for it if you
don't use it.

What beyond that? Yes I see
 , but that seems like a big thing which needs lots of thoughts.
NetworkManager mostly managed devices and IP configuration (in it's

(I'm sorry if the above link explains it all. I will read up on it!)


P.S. To be able to run patched NM you also need patched libndp
library available here:

Some comments:

it would be great if you could adhere strictly to our coding style.

+typedef struct _pvdid {
+    enum ndp_pvdid_type type;
+    guint8 len;
+    union {
+         char uuid[37];
+    };

all stuff in headers *must* have a nm/NM prefix.

Typedefs are camel cased

no // comments

we are picky about whitespace.

+    pvds = nm_device_get_pvds(device);
                             ^^^ space

#define BUFFER_SIZE»»···2048
no non-leading tabs

+// TODO: Remove this, only for debugging using printfs
+#include <stdio.h>

there is g_print(), g_message(), _LOGx(). Just use those.


#include <ndp.h>

I think we don't ever want to include ndp.h for our client headers.

+    g_dbus_method_invocation_return_value (context,
+                        g_variant_new ("(^ao)", (char **) paths));

First indention with tabs, then with spaces to align the second line.

+ * (C) Copyright 2007 - 2011 Red Hat, Inc.
+ * (C) Copyright 2008 Novell, Inc.


+     * Create a node in /var/run/netns 

no trailing whitespaces

Come see us on #nm on freenode and possibly merge individual features
early -- maybe it's beneficial to merge small parts towards the full

Great stuff!!
(looking more later)


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]