mininet与namespace

前一阵发现一个问题，就是用mininet起的主机的namespace用ip netns查看不到，一直感觉很奇怪，因为根据mininet官网给出的描述，起创建的switch，host还有自带的controller都是位于namespace下的，其中switch和自带controller都是位于root namespace下，不同host是位于不同的host下面，但是为啥子用ip netns就看不到，明明ip netns就是查看namespace的。今天有时间，上网查了一下，终于知道以前了解的namespace只是冰山一角。本文只给出概括说明，具体不同namespace的详细用法查看文章底部的链接。
总得概括来说其实就是一句话：ip netns add创建的namespace是带name的，而mininet创建的namespace是nameless的，ip netns只会显示带name的且在/var/run/netns下有挂载的namespace。所以我们看不到mininet创建的namespace。
以下为较详细的说明，现有的namespace共分为以下6种：

种类	clone创建参数
Mount namespaces	CLONE_NEWNS
UTS namespaces	CLONE_NEWUTS
IPC namespaces	CLONE_NEWIPC
PID namespaces	CLONE_NEWPID
Network namespaces	CLONE_NEWNET
User namespaces	CLONE_NEWUSER

目前Linux实现了以上6种的namespace，不同namespace是对不同资源的隔离，命名空间的一个总体目标是支持轻量级虚拟化工具container的实现，container机制本身对外提供一组进程，这组进程自己会认为它们就是系统唯一存在的进程。以下三个命令与创建命名空间相关：

clone:创建进程和namespace
unshare:使进程脱离某个namespace，其不创建进程，只创建namespace
setns:将某个进程加入到某个namespace中。

上述表格所说的参数即为clone系统调用的参数，其6个namespace的功能如下：

mount命名空间（CLONE_NEWS, Linux2.4.19）用于隔离一组进程看到的文件系统挂载点集合，即处于不同mount 命名空间的进程看到的文件系统层次很可能是不一样的。mount()和umount()系统调用的影响不再是全局的而只影响其调用进程指向的命名空间。
mount命名空间的一个应用类似chroot，然而和chroot()系统调用相比，mount 命名空间在安全性和扩展性上更好。其它一些更复杂的应用如：不同的mount命名空间可以建立主从关系，这样可以让一个命名空间的事件自动传递到另一个命名空间。
mount命名空间是Linux内核最早实现的命名空间，于2002年就开始了；这就是CLONE_NEWS的由来，当时没人想到其它不同的命名空间会被添加到内核。
UTS命名空间（CLONE_NEWUTS， Linux2.6.19）隔离了两个系统变量，系统节点名和域名；uname()系统调用返回UTS，名字使用setnodename()和setdomainname()系统调用设置。从容器的上下文看，UTS赋予了每个容器各自的主机名和网络信息服务名(NIS) (Network Information Service)，这使得初始化和配置脚本能够根据不同的名字进行裁剪。UTS源于传递给uname()系统调用的参数：struct utsname。该结构体的名字源于"UNIX Time-sharing System"。
IPC namespaces (CLONE_NEWIPC, Linux 2.6.19)隔离进程间通信资源，具体来说就是System V IPC objects and (since Linux2.6.30) POSIX message queues；这些机制的共同特点是由其特点而非文件系统路径名标识。每一个IPC命名空间尤其自己的System V IPC标识符和POSIX 消息队列文件系统。
PID namespaces (CLONE_NEWPID, Linux 2.6.24)隔离进程ID号命名空间，话句话说就是位于不同进程ID命名空间的进程可以有相同的进程ID号，PID命名空间的最大的好处是在主机之间移植container时，可以保留container内的ID号，PID命名空间允许每个container拥有自己的init进程（ID=1），init进程是所有进程的祖先，负责系统启动时的初始化和作为孤儿进程的父进程。
从特殊的角度来看PID命名空间，就是一个进程有两个ID，一个ID号属于PID命名空间，一个ID号属于PID命名空间之外的主机系统，此外，PID命名空间能够被嵌套。
Network namespaces (CLONE_NEWNET, Linux2.6.24开始结束于 Linux 2.6.29)用于隔离和网络有关的资源，这就使得每个网络命名空间有其自己的网络设备、IP地址、IP路由表、/proc/net目录、端口号等等。
从网络命名空间的角度看，每个container拥有其自己的网络设备（虚拟的）和用于绑定自己网络端口号的应用程序。主机上合适的路由规则可以将网络数据包和特定container相关的网络设备关联。例如，可以有多个web 服务器，分别存在不同的container中，这就使得这些web 服务器可以在其命名空间中绑定80端口号。
User namespaces (CLONE_NEWUSER, 起始于 Linux2.6.23 完成于 Linux 3.8) 隔离用户和组ID空间，换句话说，一个进程的用户和组ID在用户命名空间之外可以不同于命名空间之内的ID，最有趣的是一个用户ID在命名空间之外非特权，而在命名空间内却可以是具有特权的。这就意味着在命名空间内拥有全部的特权权限，在命名空间之外则不是这样。

以上关于namespace的功能内容摘自shichaog博客。
其中我们用的ip netns只是显示的是network namespace，与别的无关。我们可以通过命令ls -al /proc/[pid]/ns发现不同的进程的namespace，通过查看inode号是否一致判断是否属于同一个namespace。比如，我创建了一个mininet，我们查看各个net node属于的命名空间：
ns0
ns1
ns2
ns3
ns4
ns5
我们可以发现自带控制器c0和交换机s1都是位于和进程1同一个namespace下，也就是所谓的root namespace，当然我们也可以改变switch的namespace为新的namespace，具体可以参考这篇博客。而h1和h2的mnt和net namespace都不一样，前者是挂载的namespace，后者是网络的namespace，证明他们是位于新的namespace下。
我们用命令ip netns add创建的namespace都会在/var/run/netns下设一个挂载点，该挂载点的作用就是保证命名空间中即使没有进程也可以存在，否则命名空间不能单独存在。比如，我们用ip netns创建一个名为ns1的namespace，并查看挂载点：
ns6
我们可以看到上述结果，其中touch创建的挂载点明显不能运行，因为它只是个普通的挂载点，没有和实际的namespace联系起来。这时候朋友们就要问了：so,how？Let's move on!
答案就是只需要建一个软链接就ok了： sudo ln -s /proc/3740/ns/net /var/run/netns/h1_ns这时候你可以查看并使用这个namespace了。
本文只是说明network namespace与mininet的关系，具体关于各个namespace的详细用法可以参考下面的链接。