Vivien Chappelier <[EMAIL PROTECTED]> writes: > To bring back the discussion you had with Eric W. Biederman, it seems to > me that the only real issue is on the addition of the global nsid index > that is not really fit to be used hierarchically. However, I don't > understand why having both this global nsid interface and the pid > interface would hurt, as the goals of isolation and VRF-like support are > really separate.
A global nsid breaks migration, it breaks nested containers, in general it just hurts. So it is a bad choice for an interface. Personally if I have vrf I want to set up a test environment in a container so I can isolate it from the rest of the system. Allowing me to play with the user space side of the functionality without So these things are not completely separate concerns. So from a design point of view I see the following questions. 1) How do we pin a network namespace to allow for routing when no process uses it? 2) How do we create sockets into that pinned network namespace? 3) How do we enter that network namespace so that sockets by default are created in it? All of these are technically easy things to implement and design wise a challenge. The best solution I see at the moment is to have something (a fs) we can mount in the filesystem, keeping the network namespace alive as long as it is mounted. i.e mount -t netns none /dev/nets/1 mount -t netns -o newinstance none /dev/nets/2 (The new instance parameter creates the network namespace as well as capturing the current one) char netns[] = "/dev/nets/2" fd = socket(); err = setsockopt(fd, SOL_SOCKET, SO_NETPATH, netns, strlen(netns) + 1); Eric _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
