以下分析基于 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