以下分析基于 xen4.2.3, 虚拟机都是hvm模式

使用libxl库有两种方式启动一个虚拟机,一种是 xl create xx.conf , 这种方式从一个配置文件开始启动一个虚拟机,速度相对较慢。另一种是xl restore checkpointfile , 这种从一个checkpoint文件启动(恢复)虚拟机,速度非常快。 checkpointfile 可以认为是一个虚拟机快照,保存了虚拟机某一时刻的内存和设备状态,这里的‘某一时刻’其实就是执行保存快照  xl save domainname checkpointfile 的时刻。

一. xl  save 流程

假设一开始是从xl create的方式启动的虚拟机 domtest, 执行到某一时刻相要通过xl save保存快照,xl save 执行的时候涉及多个进程,如下:

进程1: xl create domtest.conf

进程2: qemu-dm

进程3: xl save

进程4: libxl_save_helper (xen4.2 引入的)

一般xl create虚拟机后会发生多次fork和daemon调用,但完全启动之后主要的应用层进程就是 xl create 和 Qemu-dm 两个精灵进程。xl save执行时候还涉及两个文件,如下:

文件1: /var/lib/xen/userdata-d.domid.domuuid 文件

文件2:/var/lib/xen/qemu-resume.domid 文件

xl create过程中,虚拟机的配置会被保留一份在上述文件1里,而文件2是在xl save执行过程中由qemu-dm进程产生的。

下面是 "xl save checkpointfile "  命令执行的基本过程:

1. xl save 进程将文件1拷贝到checkpointfile文件开头

2. xl save 进程调用fork, 子进程调用 execvp 载入可执行程序 libxl-save-helper 变成进程4, 这个helper进程通过 libxc 库将虚拟机的整个内存状态保存在一个虚拟地址开始的内存空间里,这个虚拟地址是启动 libxl-save-helper时由 xl save 进程传进去的

3. 在子进程执行libxl-save-helper时,父进程执行下述步骤

3.1 调用 xc_domain_shutdown 关闭虚拟机,并进入一个循环,循环内调用 xc_domain_getinfolist 查看虚拟机是否关闭,如果关闭退出循环进入3.2. 这一步执行完之后,xl create进程就死掉了

3.2 调用xenstore接口往  /local/domain/0/device-model/%d/command 键写入 'save' , 这会导致进程进程3 qemu-dm 将设备状态保存到文件 /var/lib/xen/qemu-save.xx,保存好之后,qemu-dm会进入状态paused

3.3 进入一个循环,循环内检测/local/domain/0/device-model/1/state 的值是否为 paused ,如果不是等待超时

3.4 如果在3.3超时退出,则save失败。如果没有超时,则开始等待 libxl-save-helper 进程,如果后者执行完成,则执行3.5

3.5 将 /var/lib/xen/qemu-save.xx文件的内容拷贝到checkpointfile文件,至此,虚拟机的配置、内存、设备模型都已经保存到了checkpointfile文件

3.6 杀死 qemu-dm 进程并调用 libxc 接口删除虚拟机(内核部分的清理)

二 restore 流程

restore流程跟save流程基本相反, xl restore checkpointfile

1. 从checkpointfile里读取第一部分的配置部分,根据配置分配结构启动内核进程等等

2. 调用 libxl-save-helper , 恢复内存状态

3. 将checkpointfile 的最后设备模型那部分拷贝到 /var/lib/xen/qemu-save.xx文件, 并启动 Qemu-dm 进程, qemu-save.xx 文件作为 qemu-dm 的 loadvm 参数传进去

参考:

2010 的文章,比较老了,流程跟4.2 的也有些不一样:Fast, Lightweight Virtual Machine Checkpointing

05-11 22:13