虚拟化 快照功能总结（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或重新创建新卷。