lxd是什么：lxd是基于lxc构筑的容器管理进程，提供镜像，网络，存储，以及容器的能力，对外暴漏restfull API。其与docker的区别是docker更切近与app container，以应用为中心构筑，lxd属于system container，以资源为中心构筑，其使用方式也是切近与vm，而与vm的区别，请自行搜索容器与vm差异。lxd由ubuntu开源，意在提供资源视角的容器，不颠覆传统的资源的运维管理方式。其配套由openstack的nova-lxd driver 可与openstack轻松集成，管理vm方式管理容器。
本篇重点说的是lxd daemon的启动篇：
由上面可知，我们可以通过启动参数配置 对lxd的运行阶段进行全方位的跟踪，有cpu，内存，以及运行堆栈的信息，这对lxd的问题定位很有帮助。lxd daemon守护进程的启动重点在daemon初始化过程中：
下面对红色部分详细展开解释：
从启动篇看具备如下能力：
1：支持apparmor
2：支持storage driver：为容器设置不同的文件系统
3：支持bridge和ovs两种网络方式
4：支持cpu，net，usb热插拔
5：:支持GPU设备发现加载
6：支持代理服务器访问
此部分涉及Linux 较多知识。将涉及的简单概括：
Namespace
Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的，而是属于某个特定的Namespace。每个namespace下的资源对于其他namespace下的资源都是透明，不可见的。因此在操作系统层面上看，就会出现多个相同pid的进程。系统中可以同时存在两个进程号为0,1,2的进程，由于属于不同的namespace，所以它们之间并不冲突。而在用户层面上只能看到属于用户自己namespace下的资源，例如使用ps命令只能列出自己namespace下的进程。这样每个namespace看上去就像一个单独的Linux系统。
User Namespace主要是用了CLONE_NEWUSER的参数，使用了这个参数后，内部看到的UID和GID已经与外部不同了。默认情况下容器没有的UID，系统自动设置上了最大的UID65534，默认UID的定义文件在“/proc/sys/kernel/overflowuid”。
要把容器中的uid和真实系统的uid给映射在一起，需要修改 /proc/$$/uid_map 和/proc/$$/gid_map 这两个文件。这两个文件的格式为：
ID-inside-ns ID-outside-ns length
PS：
第一个字段ID-inside-ns表示在容器显示的UID或GID，
第二个字段ID-outside-ns表示容器外映射的真实的UID或GID。
第三个字段表示映射的范围，一般填1，表示一一对应。
例：把真实的uid=1000映射成容器内的uid=0
$cat/proc/2465/uid_map
0 1000 1
例：把namespace内部的uid映射到外部设置整形
把namespace内部从0开始的uid映射到外部从0开始的uid，其最大范围是无符号32位整形
$cat/proc/$$/uid_map
0 0 4294967295
需要注意的是：
写这两个文件的进程需要这个namespace中的CAP_SETUID (CAP_SETGID)权限(可参看Capabilities)写入的进程必须是此user namespace的父或子的user namespace进程。
另外需要满如下条件之一：
1)父进程将effective uid/gid映射到子进程的user namespace中
2)父进程如果有CAP_SETUID/CAP_SETGID权限，那么它将可以映射到父进程中的任一uid/gid
AppArmor
AppArmor(Application Armor)是Linux内核的一个安全模块，AppArmor允许系统管理员将每个程序与一个安全配置文件关联，从而限制程序的功能。简单的说，AppArmor是与SELinux类似的一个访问控制系统，通过它你可以指定程序可以读、写或运行哪些文件，是否可以打开网络端口等。作为对传统Unix的自主访问控制模块的补充，AppArmor提供了强制访问控制机制，它已经被整合到2.6版本的Linux内核中。
详细介绍参考：http://www.cnblogs.com/-Lei/archive/2013/02/24/2923947.html
网络
设置涉及iptables，ip link命令，ovs-vsctl命令。
unix domain socket
相关 参考：http://www.th7.cn/Program/go/201508/539156.shtml
Linux内核态与用户态通信
参考：http://blog.csdn.net/luckyapple1028/article/details/50839395