lxc介绍

LXC又名Linux container，是一种虚拟化的解决方案，这种是内核级的虚拟化。(主流的解决方案Xen ,KVM, LXC)

Linux Container容器是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。可以最大效率隔离进程和资源。它可以把传统虚拟技术以及后来的Xen、KVM的VM进程像HOST进程一样运行管理, 所以创建和销毁都非常轻。

如果说LXC着眼点在于提供轻量级的虚拟技术，扎根在虚拟机，那Docker则定位于应用。

概述

LXC为Linux Container的简写。可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的NameSpace。容器有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。与传统虚拟化技术相比，它的优势在于：

（1）与宿主机使用同一个内核，性能损耗小；

（2）不需要指令级模拟；

（3）不需要即时(Just-in-time)编译；

（4）容器可以在CPU核心的本地运行指令，不需要任何专门的解释机制；

（5）避免了准虚拟化和系统调用替换中的复杂性；

（6）轻量级隔离，在隔离的同时还提供共享机制，以实现容器与宿主机的资源共享。

总结：Linux Container是一种轻量级的虚拟化的手段。

Linux Container提供了在单一可控主机节点上支持多个相互隔离的server container同时执行的机制。Linux Container有点像chroot，提供了一个拥有自己进程和网络空间的虚拟环境，但又有别于虚拟机，因为lxc是一种操作系统层次上的资源的虚拟化。

备注：内核和操作系统是同个层次，所以称作内核虚拟机化技术，也称作操作系统层次的虚拟化技术

LXC的实现

编辑

Sourceforge上有LXC这个开源项目。LXC项目本身只是一个为用户提供一个用户空间的工具集，用来使用和管理LXC容器。LXC真正的实现则是靠Linux内核的相关特性，LXC项目只是对此做了整合。基于容器的虚拟化技术起源于所谓的资源容器和安全容器。

LXC在资源管理方面依赖于Linux内核的cgroups子系统，cgroups子系统是Linux内核提供的一个基于进程组的资源管理的框架，可以为特定的进程组限定可以使用的资源。LXC在隔离控制方面依赖于Linux内核的namespace特性，具体而言就是在clone时加入相应的flag（NEWNS NEWPID等等）。

LXC架构的介绍

通过namespace进行资源的隔离,Guest1下的进程与Guset2下的进程是独立的，可以看作运行在两台物理机上一样。Contaniner管理工具就是对Guest进行管理的(创建、销毁)。

图是对LXC架构的介绍

下图是LXC与KVM技术的比较,KVM的优点是一个物理机上可以跑多个操作系统(Guest-OS),然后在每个操作系统运行应用,通过这种方式实现应用的隔离。而使用LXC技术直接可以在Host-OS的基础上实现隔离的。这就是LXC的优势--运行快。但是，如果有两个应用一个是在windows运行的，一个是在linux上运行的，这时只能使用KVM技术来实现了。

container管理工具

container与KVM的比较

container并未实现完全虚拟化，在Guest-OS中执行的一些操作会直接影响到HOST-OS。下面是两者的对比。

LXC具体组成

LXC项目在Sourceforge上面的，它有一个Linux内核补丁和一些用户空间的工具组成，其中内核补丁提供底层新特性，上层工具使用这些新特性，提供一套简化的工具来维护容器。

LXC在资管管理方面，依赖与Linux内核密切相关的Cgroups子系统，这个子系统是Linux内核提供的一个基于进程组的资源管理框架，可以为特定的进程组限定可以使用的资源，借助cgroups子系统，在当前Linux环境下，实现一个轻量化的虚拟机。

LXC在隔离控制方面，依赖于Linux内核提供的namespace特性，具体来说，就是在clone的时候加入相应的flag。

LXC的优势

LXC是操作系统层面的虚拟化技术，与传统的HAL层次的虚拟化技术相比，有以下优势：

1. 更小的虚拟化开销。LXC的诸多特性基本有内核提供

2. 快速部署。只需要安装LXC，就可以利用LXC的相关命令来创建并且启动容器，为应用提供虚拟执行环节。而传统的虚拟化技术，需要先创建虚拟机，然后安装系统，再部署应用。

3. 虚拟机的rootfs就在/var/lib/lxc/container_name ，可以在宿主机上轻松修改container的文件系统。

4. LXC使用apparmor，应用程序访问控制系统来确保主机不受容器内实例的恶意行为。

LXC的缺点

1. 缺少对磁盘限额(disk quota)的支持，目前使用LVM来限定支持。

2. 缺少对写时复制(copy on write)的支持，对于每个容器来说，都是一份操作系统的用户态实例，都有属于自己的系统库函数文件等必需文件。在一个系统有多个容器的情况下，这会造成磁盘空间的浪费。这里可以借鉴写时复制的概念，对于容器共用的文件，在没有对共享文件进行写入之前，可以只保存一份拷贝，其他容器采用硬链接的方式来共享，当有容器对共享文件进行写入时，为其单独创建一份拷贝。

3. 进程和容器之间的动态关联还不够完善

理想情况下，进程和容器之间是动态关联的，进程可以在容器之间迁移。在LXC中，资源管理是通过cgroups实现的，进程可以在cgroup之间有条件的迁移。命名空间的隔离是通过namespace实现的，目前内核只支持进程变更有限的几类命名空间。

4. 不支持checkpoint

checkpoint技术可以将容器中所有的进程暂时frozen，将当时容器完整的状态存储在磁盘上，类似于Vmware的snapshot，目前LXC不支持checkpoint技术，只是借助cgroups的freezer子系统，将进程暂时frozen和resume，没有完整的存储容器的状态。

5. 不支持容器的动态迁移

动态迁移是指将正在运行的容器从一个机器上迁移到另一个机器上，在此过程中，容器中的进程无需停止，此项技术可以用来优化服务器集群的资源配置。目前LXC不支持动态迁移。

namespace介绍

Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的(在Linux2.6内核以前是全局的)，而是属于特定的Namespace。每个Namespace里面的资源对其他Namespace都是透明的。namespace是container中使用到的重要技术之一，是对系统资源的操作上的隔离。使Guest-OS1的操作对Guest-OS2无法产生影响。

当然namespace的实现还在完善中，下面是3.8以上的内核实现的namespace

Mount

Mount namespace是对挂载的文件系统布局进行隔离。图中显示在Namespace1中的进程看到的文件系统的挂载方式是一致的，但是在Mount Namespace2中看到的是一另一种情况

IPC

处于同一namespace下的进程才可以进行进程间通信。

NET

NET NAMESPACE实现网络协议栈上的隔离，在自己的namespace中对网络的设置只能在本namespace中生效。

PID

我们通过fork来创建进程时可以为每个进程指定命名空间。linux下的进程关系是一棵树，所以有了父命名空间和子名字空间之分。

在namespace2创建的P2进程有两个pid。第一个是在父命名空间的下的它的PID号，一个是在自己空间下的PID号。之所以有父pid号是因为P2最终还是在父命名空间下运行的，而为进程指定命名空间是为了让P2和P3实现隔离。

USER

User namespace中使用到了map转换，由于container并不是真正的虚拟化，所以在Guest-OS中创建的root用户会被映射到Host-OS中的普通用户中去。

下图中的例子中，root用户在自己的namespace下创建了一个文件，那这个文件的所有者ID应该是0，当时在磁盘上存的时候文件UID会被转换为kuid,并且所有者ID为1000。想说名一点是在Guest-OS下你是个root用户，但是在Host-OS你只不过被转为一个普通用户而已。因为我们知道在Host-OS下已经有一个root用户了。