Posts Tagged ‘CRIU’

为 LXC 配置网络

October 16th, 2015

LXC是一个基于cgroup 与 namespace 机制的轻量级虚拟机,在Ubuntu平台下有专门的源,可以直接通过apt-get安装,但是在debian平台下,软件仓库中lxc版本太低,导致很多新特性无法使用,推荐源码安装。截止到我写这篇博客,lxc版本已经更新至1.1.4 。

首先我们首先要编译安装最新版的LXC,根据教程INSTALL,我们需要运行autogen.sh ./configure 生成Makefile,这里必须将LXC 中的Security feature 全部安装,否则无法通过lxc-start 启动容器。

为容器配置网络有两种形式:1) 使用网桥    2) 直接使用物理网卡

1) 使用网桥

假设我们主机只有eth0的物理网卡,在主机/etc/network/interfaces中,直接加入下面的字段:

auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_fd 0
        bridge_maxwait 0

然后重启网络 /etc/init.d/networking restart 之后可以发现主机网络出现br0的网桥。

如果LXC在编译时没有配置路径,容器的config默认路径在/usr/local/var/lib/lxc/xxx/config ,我们需要在这个文件中加入网络选项

lxc.network.type = veth
lxc.network.flags = up

# that's the interface defined above in host's interfaces file
lxc.network.link = br0

# name of network device inside the container,
# defaults to eth0, you could choose a name freely
# lxc.network.name = lxcnet0 

lxc.network.hwaddr = 00:FF:AA:00:00:01

然后我们在容器的/etc/network/interfaces中,添加

auto eth0
iface eth0 inet dhcp

如果容器中没有开启dhclient服务,最好将其加到 /etc/rc.local中即可。

2) 直接使用物理网卡

比如物理宿主主机拥有两张网卡:eth0 与 eth1,我把eth0作为主机使用,eth1作为LXC使用。那么我们在config中添加

xc.network.type=phys
lxc.network.link=eth1
lxc.network.flags=up
#lxc.network.hwaddr = 00:16:3e:f9:ad:be #注释掉#

lxc.network.flags 用于指定网络的状态,up 表示网络处于可用状态。
lxc.network.link 用于指定用于和容器接口通信的真实接口,比如一个网桥 br0 ,eth0等。

在主机/etc/network/interfaces中加入

auto eth1
iface eth1 inet dhcp

然后重新启动网络服务 #/etc/init.d/networking restart
重新启动 LXC 容器 # lxc-start -n xxx

一旦 LXC 虚拟计算机启动成功,在宿主计算机上使用〝ifconfig -a〞查看主机网络接口,用户会发现此时网络接口 eth1 消失了,只有 eth0 。这是因为 eth1 已经让 LXC 虚拟计算机给使用了。然后我们使用如下命令“ lxc-attach -n xxx”登录 LXC 虚拟计算机发现此时 LXC 虚拟计算机的网络接口是 eth1。然后我们可以使用 ping 命令测试一下 LXC 虚拟计算机和互联网是否联通。

3) 容器配置静态IP

如果我们使用静态IP的话,宿主机可以使用静态IP或者是DHCP,我们假定宿主机是DHCP,容器是静态IP,注意最后两个字段:

lxc.network.type = veth
lxc.network.flags = up

# that's the interface defined above in host's interfaces file
lxc.network.link = br0

# name of network device inside the container,
# defaults to eth0, you could choose a name freely
# lxc.network.name = lxcnet0 

lxc.network.hwaddr = 00:FF:AA:00:00:01
lxc.network.ipv4 = 192.168.1.110/24#注意设置为宿主机的网段
lxc.network.ipv4.gateway = 192.168.1.1#注意设置为宿主机的网段

在容器内的/etc/network/interfaces中加入,记住不加auto eth0!

iface eth0 inet static
       address <container IP here, e.g. 192.168.1.110>
       netmask 255.255.255.0
       network <network IP here, e.g. 192.168.1.0>
       broadcast <broadcast IP here, e.g. 192.168.1.255>
       gateway <gateway IP address here, e.g. 192.168.1.1>
       # dns-* options are implemented by the resolvconf package, if installed
       dns-nameservers <name server IP address here, e.g. 192.168.1.1>
       dns-search your.search.domain.here

结束:

根据我与CRIU团队的交流,目前CRIU不支持对于LXC独占物理网卡的c/r ,对于某些application使用 SOCK_PACKET 的套接字目前也不支持!这个特性已被加到criu新特性中,https://github.com/xemul/criu/issues/73 。预计在之后的版本中支持!

 

https://www.ibm.com/developerworks/cn/linux/1312_caojh_linuxlxc/

https://wiki.debian.org/LXC/SimpleBridge

由lxc-checkpoint想到的 …

May 12th, 2015

在 LXC 1.1版本以后,lxc整合了criu的功能,使得可以checkpoint一个正在运行的容器。但是有时候我们会出现lxc.tty must be 0的文字,这个就意味着我们必须在lxc 的config中加入特定的选项

cat | sudo tee -a /var/lib/lxc/u1/config << EOF
# hax for criu
lxc.console = none
lxc.tty = 0
lxc.cgroup.devices.deny = c 5:1 rwm
EOF

但是我发现了一个问题:到底什么是tty,他是由什么管理的?

我们都知道在unix下有非常多的终端:bash、zsh、sh、ssh等,这些终端程序就是我们输入命令的窗口,至于配置用户的终端,当然是在/etc/passwd下面。

但是是哪个程序调用了/bin/bash呢?使用strace跟踪这个/bin/login(strace -f -o /tmp/strace.log /bin/login),可以发现里面存在execve系统调用,这个调用执行了 /bin/login程序。而login又是谁调用的呢?经过查看是getty。getty是在自己的主进程里头直接执行了/bin/login,这样/bin/login将把getty的进程空间替换掉。

而init需要读取/etc/inittab来做,inittab,目前不再被systemd使用,这里就有/etc/rc.d/一系列脚本完成。
根据系统启动原理,我们可以发现调用过程:

init –> init –> /sbin/getty –> /bin/login –> /bin/login –> /bin/bash

这里的execve调用以后,后者将直接替换前者,我们要知道一点:因为终端程序之间有父子关系的存在,当子进程exit之后,父进程要进行处理,否则就是zombie进程。因此当我们键入exit退出/bin/bash以后,也就相当于/sbin/getty都已经结束了, 因此最前面的init程序判断/sbin/getty退出了,又会创建一个子进程把/sbin/getty启动,进而又启动了/bin/login,又看 到了那个”XXX login:”

一般情况下,系统内置程序会比自己编写的更加优先被执行,按照系统内置规则,一般首先是程序别名,然后是shell function,之后是系统内置函数(builtin ),最后才是自己编写的函数(program )!

总的来说:先    alias –> shell function –> builtin –> program   后 

 

参考:

[1] man boot-scripts Linux启动过程
[2] man bootparam  Linux内核启动参数
[3] man 5 passwd
[4] man shadow

Checkpoint/Restore in user space:CRIU

March 20th, 2015

Update 2015-3-23

CRIU 是一款目前流行的应用程序级的检查点恢复程序,这个基于OpenVZ 项目,但是OpenVZ项目最大的弊端是需要修改原有kernel。而CRIU则尽可能将程序主体放在用户空间,内核空间只保留必要的system call。

目前OpenVZ的开发,只停留在kernel 2.6.32上面,主要开发人员已经把他们的开发重点放在CRIU上面。

用户态下的CRIU程序我们不会细说,我们主要关注kernel中CRIU。包括两部分:1)需要一种mechanism去dump kernel关于该进程的某个特定信息。2)将状态信息传递给内核进行恢复。

CRIU的目标是允许整个application的运行状态可以被dump,这里就要去dump非常多的与这个application相关的信息,主要包括[1]:

  • virtual memory map
  • open files
  • credential
  • timer
  • PID
  • parent PID
  • share resources

dump 一个特定application的途径就是:

  • Parasite code[2] 这个代码可以hack进一个特定进程,对进程透明的进行监控,获取文件描述符。dump memory content。实际原理就是在正常程序执行前,先执行Parasite code,实际的例子就是getitimer()和sigaction()。
  • Ptrace 可以迅速freeze processes,注入parasite code。
  • Netlink 获取 sockets,netns信息。
  • 获取procfs 中特定PID的内容,/proc/PID/maps  /proc/PID/map_files/ /proc/PID/status  /proc/PID/mountinfo ,其中/proc/PID/map_files。这个map_files包括文件,网络等

Parasite code不是专门为CRIU设计,而是kernel的加入的特性,而CRIU使用了Parasite code去调用某些只能是application自己调用的system call,比如getitimer()。

除了一些特殊的system call,另外一些call可以由任意形式的程序进行调用,比如sched_getscheduler()获取调度器,使用sche_getparam()获取进程调度参数。

Ptrace 是一个system call,使用这个ptrace,可以做到控制目标进程,包括目标状态的内部信息,常用于debug和其他的代码分析工具。在kernel 3.4之前,ptrace非常依赖signal与目标进程交互,这就意味会打断进程执行,非常类似于gdb等工具,而加入PTRACE_SEIZE并不会停止进程。

ptrace新特性的引入,使得CRIU可以用来对于某个特定application进行checkpoint。

Restore一个application:

  • Collect shared object
  • Restore namespace
  • 创建进程树,包括SID,PGID,恢复继承
  • files,socket,pipes
  • Restore per-task properties
  • Restore memory
  • Call sigreturn

特定kernel的feature:

  • Parasite code[2]
  • 如果一个程序打开了一系列的各种形式的文件,kernel在内核中会保存一个文件描述符表来记录该application打开哪些文件,在恢复时,CRIU要重新打开该这些文件,以相同的fd号。在恢复某些特定的pid 的application,发现pid被占用,如果我们想要恢复这个进程,而且继续使用这个pid值,CRIU在内核中加入一个API来控制下几个fork即将分配的pid值,主要是/proc/sys/kernel/ns_last_pid 。主要是向具体参见:http://lwn.net/Articles/525723/
  • kernel还添加了kcmp()的system call,用来比较两个进程是否共享一个kernel资源。这个就用在父进程打开一系列的share resource,然后fork()。子进程继承父进程的resource,这时kcmp()派上用场。
  • /proc/PID/map_files
  • prctl拓展来设置匿名的,私有的对象。eg: task/mm object
  • 通过netlink dump socket信息。在scoket恢复中,相比于/proc file,通过这个可以获取更多的socket信息,通过这些信息,CRIU使用getsockopt(),setsockopt()恢复socket链接。
  • TCP repair mode
  • virtual net device indexes,在一个命名空间中恢复网络设备
  • socket peeking offset
  • Task memory tracking,用于增量快照与线上迁移。

 总的来说CRIU与OpenVZ有几分相似,二者最大的区别就是OpenVZ需要修改内核,非常不便,而CRIU依赖kernel加入的systemcall完成,对于内核没有要求,非常轻便。

而BLCR也是根据某个特定kernel 版本开发,它由两个kernel module,用户态lib工具组成。使用BLCR恢复进程,进程必须依赖libcr库,或者编译时将libcr加入。这个显然对于老旧代码非常不便。BLCR最新版本发布的时候2013.1

而CRIU 截止目前最新版本发布在2015.3.2 ,可以看出CRIU开发非常活跃。

CRIU.pdf

参考:

[1] http://lwn.net/Articles/525675/

[2]  http://lwn.net/Articles/454304/

BCLR:

http://blog.csdn.net/myxmu/article/details/8948258

http://blog.csdn.net/myxmu/article/details/8948265