虚拟化 快照功能总结（libvirt，openstack）
Libvirt快照
内部快照：
1.内部快照不支持raw格式
（raw 启动的虚拟机会比QCOW2 启动的虚拟机I/O 效率更高一些(25%)
qcow2是一种当下比较主流的虚拟化磁盘格式，具有占用空间小，支持加密，支持压缩，支持快照的特点）
2.使用单个的qcow2 的文件来保存快照和快照之后的改动 过程较慢 本质是在镜像内做一些标记
创建：virsh snapshot-create-as --name snap001--description '001' instance-00000002
恢复：
virsh snapshot-revert instance-00000002 --snapshotname snap002
开机快照/恢复会挂起系统 较耗时 可正常恢复快照 内存快照 同时挂载的云硬盘也会生产快照在恢复时一起恢复。
外部快照：
1.创建完外部快照后，原镜像文件会变成只读，新的变更都会写入到新的快照文件中。新的快照使用前一个快照的镜像文件作为backing file
2.其快照之间存在链式关系，基中任一环节出现问题，都会出现无法还原到之间状态
3.使用“--memspec” 和“--diskspec” 参数支持 内存和磁盘外部快照
4. libvirt现在还不支持回滚和删除外置快照（直接restore 和delete 有其他办法，较复杂）
挂载的其他盘无法一起做快照需要分开
Openstack快照
1. volume backed以外类型的虚拟机，在nova-api中调用API.snapshot接口创建快照（最终实现在createImage接口）
volume backed的虚拟机，在nova-api中调用API.snapshot_volume_backed接口创建虚拟机快照
boot from image:
a.pause instance
b.执行qemu-img convert 命令复制disk 文件，生成快照文件
c.resume instance
d.将快照文件上传到Glance
boot from volume:
利用storage provider 自己的snapshot 技术实现快速复制
(boot from volume 其实是OpenStack 部署instance 的最佳实践，instance 的启动盘和数据盘都由cinder 管理)
2.openstack 虚拟机的快照即是镜像，快照做完后以镜像形式存于glance
1.没有快照链信息，不支持revert恢复虚拟机到某一个快照点，只能采用该快照镜像创建一个新的虚拟机
2.nova image-create 会对系统盘和挂载的云硬盘同时分别生产快照。但是不能同时恢复。
nova volume-snapshot-create不能对in-use的卷做快照
无法直接恢复快照（实际是镜像）。
可以通过rebild 使用指定快照恢复虚拟机
nova rebuild --name vm_name f37aa73f-1379-4ee7-bd85-1c31df7f7905 7c21543f-64e6-4361-84ae-626ae18bb3b2
可恢复系统卷 但挂载的云硬盘没有恢复。
分析总结
1. Snapshot 依赖于源volume，不能独立存在；而backup 不依赖源volume，即便源volume 不存在了，也可以restore。
2. Snapshot 与源volume 通常存放在一起，都由同一个volume provider 管理；而backup 存放在独立的备份设备中，有自己的备份方案和实现，与volume provider 没有关系。
3. 上面两点决定了backup 具有容灾功能；而snapshot 则提供volume provider 内便捷的回溯功能。
应该尽量避免在虚机I/O繁忙的时候做快照。这种时候做快照不是可取的办法。
vmware 的做法是装一个tools，它是个PV driver，可以在做快照的时候挂起系统
libvirt 的内部快照 效果最好但速度较慢。功能最全。外部快照较难维护，开发复杂，创建时间较内部快照快一点。
Openstack 基于volume的快照 速度较快，不支持内存快照。依赖于存储driver。系统卷和挂载的卷得分别恢复。没有直接的revert操作，需rebuild或重新创建新卷。