[转] External(and Live) snapshots with libvirt

时间:2023-01-06 10:42:03

http://kashyapc.com/

Raw image is a blob of data exposed directly in VM as block device, it can't snapshot. qemu-img is able to import data from raw image into qcow2 image, and save it as snapshot

Previously, I posted about snapshots here , which briefly discussed different types of snapshots. In this post, let’s explore how external snapshots work. Just to quickly rehash, external snapshots are a type of snapshots where, there’s a base image(which is the original disk image), and then its difference/delta (aka, the snapshot image) is stored in a new QCOW2 file. Once the snapshot is taken, the original disk image will be in a ‘read-only’ state, which can be used as backing file for other guests.

It’s worth mentioning here that:

  • The original disk image can be either in RAW format or QCOW2 format. When a snapshot is taken, ‘the difference’ will be stored in a different QCOW2 file
  • The virtual machine has to be running, live. Also with Live snapshots, no guest downtime is experienced when a snapshot is taken.
  • At this moment, external(Live) snapshots work for ‘disk-only’ snapshots(and not VM state). Work for both disk and VM state(and also, reverting to external disk snapshot state) is in-progress upstream(slated for libvirt-0.10.2).

Before we go ahead, here’s some version info, I’m testing on Fedora-17(host), and the guest(named ‘daisy’) is running Fedora-18(Test Compose):


[root@moon ~]# rpm -q libvirt qemu-kvm ; uname -r
libvirt-0.10.1-3.fc17.x86_64
qemu-kvm-1.2-0.2.20120806git3e430569.fc17.x86_64
3.5.2-3.fc17.x86_64
[root@moon ~]#

External disk-snapshots(live) using QCOW2 as original image:
Let’s see an illustration of external(live) disk-only snapshots. First, let’s ensure the guest is running:


[root@moon qemu]# virsh list
Id Name State
----------------------------------------------------
3 daisy running [root@moon qemu]#

Then, list all the block devices associated with the guest:


[root@moon ~]# virsh domblklist daisy --details
Type Device Target Source
------------------------------------------------
file disk vda /export/vmimgs/daisy.qcow2 [root@moon ~]#

Next, let’s create a snapshot(disk-only) of the guest this way, while the guest is running:


[root@moon ~]# virsh snapshot-create-as daisy snap1-daisy "snap1 description" \
--diskspec vda,file=/export/vmimgs/snap1-daisy.qcow2 --disk-only --atomic

Some details of the flags used:
- Passing a ‘–diskspec’ parameter adds the ‘disk’ elements to the Snapshot XML file
- ‘–disk-only’ parameter, takes the snapshot of only the disk
- ‘–atomic’ just ensures either the snapshot is run completely or fails w/o making any changes

Let’s check the information about the just taken snapshot by running qemu-img:


[root@moon ~]# qemu-img info /export/vmimgs/snap1-daisy.qcow2
image: /export/vmimgs/snap1-daisy.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 2.5M
cluster_size: 65536
backing file: /export/vmimgs/daisy.qcow2
[root@moon qemu]#

Apart from the above, I created 2 more snapshots(just the same syntax as above) for illustration purpose. Now, the snapshot-tree looks like this:


[root@moon ~]# virsh snapshot-list daisy --tree snap1-daisy
|
+- snap2-daisy
|
+- snap3-daisy [root@moon ~]#

For the above example image file chain[ base<-snap1<-snap2<-snap3 ], it has to be read as – snap3 has snap2 as its backing file, snap2 has snap1 as its backing file, and snap1 has the base image as its backing file. We can see the backing file info from qemu-img:


#--------------------------------------------#
[root@moon ~]# qemu-img info /export/vmimgs/snap3-daisy.qcow2
image: /export/vmimgs/snap3-daisy.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 129M
cluster_size: 65536
backing file: /export/vmimgs/snap2-daisy.qcow2
#--------------------------------------------#
[root@moon ~]# qemu-img info /export/vmimgs/snap2-daisy.qcow2
image: /export/vmimgs/snap2-daisy.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 3.6M
cluster_size: 65536
backing file: /export/vmimgs/snap1-daisy.qcow2
#--------------------------------------------#
[root@moon ~]# qemu-img info /export/vmimgs/snap1-daisy.qcow2
image: /export/vmimgs/snap1-daisy.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 2.5M
cluster_size: 65536
backing file: /export/vmimgs/daisy.qcow2
[root@moon ~]#
#--------------------------------------------#

Now, if we do not need snap2 any more, and want to pull all the data from snap1 into snap3, making snap1 as snap3′s backing file, we can do a virsh blockpull operation as below:


#--------------------------------------------#
[root@moon ~]# virsh blockpull --domain daisy --path /export/vmimgs/snap3-daisy.qcow2 \
--base /export/vmimgs/snap1-daisy.qcow2 --wait --verbose
Block Pull: [100 %]
Pull complete
#--------------------------------------------#

Where, –path = path to the snapshot file, and –base = path to a backing file from which the data to be pulled. So from above example, it’s evident that we’re pulling the data from snap1 into snap3, and thus flattening the backing file chain resulting in snap1 as snap3′s backing file, which can be noticed by running qemu-img again.
Thing to note here,


[root@moon ~]# qemu-img info /export/vmimgs/snap3-daisy.qcow2
image: /export/vmimgs/snap3-daisy.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 145M
cluster_size: 65536
backing file: /export/vmimgs/snap1-daisy.qcow2
[root@moon ~]#

A couple of things to note here, after discussion with Eric Blake(thank you):

- If we do a listing of the snapshot tree again(now that ‘snap2-daisy.qcow2′ backing file is no more in use),


[root@moon ~]# virsh snapshot-list daisy --tree
snap1-daisy
|
+- snap2-daisy
|
+- snap3-daisy
[root@moon ~]#

one might wonder, why is snap3 still pointing to snap2? Thing to note here is, the above is the snapshot chain, which is independent from each virtual disk’s backing file chain. So, the ‘virsh snapshot-list’ is still listing the information accurately at the time of snapshot creation(and not what we’ve done after creating the snapshot). So, from the above snapshot tree, if we were to revert to snap1 or snap2 (when revert-to-disk-snapshots is available), it’d still be possible to do that, meaning:

It’s possible to go from this state:
base <- snap123 (data from snap1, snap2 pulled into snap3)

we can still revert to:

base<-snap1 (thus undoing the changes in snap2 & snap3)

External disk-snapshots(live) using RAW as original image:
With external disk-snapshots, the backing file can be RAW as well (unlike with ‘internal snapshots’ which only work with QCOW2 files, where the snapshots and delta are all stored in a single QCOW2 file)

A quick illustration below. The commands are self-explanatory. It can be noted the change(from RAW to QCOW2) in the block disk associated with the guest, before & after taking the disk-snapshot (when virsh domblklist command was executed)


#-------------------------------------------------#
[root@moon ~]# virsh list | grep f17btrfs2
7 f17btrfs2 running
[root@moon ~]#
#-------------------------------------------------#
[root@moon ~]# qemu-img info /export/vmimgs/f17btrfs2.img
image: /export/vmimgs/f17btrfs2.img
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.5G
[root@moon ~]#
#-------------------------------------------------#
[root@moon qemu]# virsh domblklist f17btrfs2 --details
Type Device Target Source
------------------------------------------------
file disk hda /export/vmimgs/f17btrfs2.img [root@moon qemu]#
#-------------------------------------------------#
[root@moon qemu]# virsh snapshot-create-as f17btrfs2 snap1-f17btrfs2 "snap1-f17btrfs2-description" \
--diskspec hda,file=/export/vmimgs/snap1-f17btrfs2.qcow2 --disk-only --atomic
Domain snapshot snap1-f17btrfs2 created
[root@moon qemu]#
#-------------------------------------------------#
[root@moon qemu]# qemu-img info /export/vmimgs/snap1-f17btrfs2.qcow2
image: /export/vmimgs/snap1-f17btrfs2.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
backing file: /export/vmimgs/f17btrfs2.img
[root@moon qemu]#
#-------------------------------------------------#
[root@moon qemu]# virsh domblklist f17btrfs2 --details
Type Device Target Source
------------------------------------------------
file disk hda /export/vmimgs/snap1-f17btrfs2.qcow2
[root@moon qemu]#
#-------------------------------------------------#

Also note: All snapshot XML files, where libvirt tracks the metadata of snapshots are are located under /var/lib/libvirt/qemu/snapshots/$guestname (and the original libvirt xml file is located under /etc/libvirt/qemu/$guestname.xml)

[转] External(and Live) snapshots with libvirt的更多相关文章

  1. External &lpar;and Live&rpar; snapshots with libvirt

    list all the block devices associated with the guest $ virsh domblklist testvm --details Type Device ...

  2. 别以为真懂Openstack&colon; 虚拟机创建的50个步骤和100个知识点&lpar;3&rpar;

    四.Nova-compute 步骤17:nova-compute接收到请求后,通过Resource Tracker将创建虚拟机所需要的资源声明占用 步骤18:调用Neutron API配置Networ ...

  3. QEMU KVM Libvirt手册&lpar;5&rpar; &ndash&semi; snapshots

    前面讲了QEMU的qcow2格式的internal snapshot和external snapshot,这都是虚拟机文件格式的功能. 这是文件级别的. 还可以是文件系统级别的,比如很多文件系统支持s ...

  4. KVM 介绍(7):使用 libvirt 做 QEMU&sol;KVM 快照和 Nova 实例的快照 (Nova Instances Snapshot Libvirt)

    学习 KVM 的系列文章: (1)介绍和安装 (2)CPU 和 内存虚拟化 (3)I/O QEMU 全虚拟化和准虚拟化(Para-virtulizaiton) (4)I/O PCI/PCIe设备直接分 ...

  5. kvm&plus;libvirt虚拟机快照浅析&lbrack;转&rsqb;

    浅析snapshots, blockcommit,blockpull 作者:Kashyap Chamarthy <kchamart#redhat.com> Date: Tue, 23 Oc ...

  6. External Snapshot management

    External Snapshot management Symptom As of at least libvirt 1.1.1, external snapshot support is inco ...

  7. QEMU KVM libvirt手册&lpar;4&rpar; &ndash&semi; images

    RAW raw是默认的格式,格式简单,容易转换为其他的格式.需要文件系统的支持才能支持sparse file 创建image # qemu-img create -f raw flat.img 10G ...

  8. &lbrack;转&rsqb; Snapshotting with libvirt for qcow2 images

    http://kashyapc.com/2011/10/04/snapshotting-with-libvirt-for-qcow2-images/ Libvirt 0.9.6 was recentl ...

  9. KVM&lpar;七&rpar;使用 libvirt 做 QEMU&sol;KVM 快照和 Nova 实例的快照

    本文将梳理 QEMU/KVM 快照相关的知识,以及在 OpenStack Nova 中使用 libvirt 来对 QEMU/KVM 虚机做快照的过程. 1. QEMU/KVM 快照 1.1 概念 QE ...

随机推荐

  1. T-Sql(五)xml操作

    t-sql中的xml操作在我们平时做项目的过程中用的很少,因为我们处理的数据量很少,除非一些用到xml的地方,t-sql中xml操作一般用在数据量很大,性能优化的地方,当然我在平时做项目的时候也是没用 ...

  2. 基于谷歌地图的Dijkstra算法水路路径规划

    最终效果图如下: 还是图.邻接表,可以模拟出几个对象=>节点.边.路径.三个类分别如下: Node 节点: using System; using System.Collections.Gene ...

  3. Android知识体系图

    网上看到,不知哪位大神总结的,存个档(需要放大网页才能看清)

  4. 3D数学 ---- 矩阵和线性变换&lbrack;转载&rsqb;

    http://blog.sina.com.cn/s/blog_536e0eaa0100jn7c.html 一般来说,方阵能描述任意线性变换.线性变换保留了直线和平行线,但原点没有移动.线性变换保留直线 ...

  5. History(历史)命令用法15例

    导读 如果你经常使用 Linux 命令行,那么使用 history(历史)命令可以有效地提升你的效率,本文将通过实例的方式向你介绍 history 命令的 15 个用法. 使用 HISTTIMEFOR ...

  6. 【找规律】CodeForce &num;258 Problem A——Game With Sticks

    来源:点击打开链接 非常easy.找规律. 每去掉一个点,点的总数量就减去n+m-1,然后看谁最先减到没有点可减.就能够了. #include <iostream> #include &l ...

  7. SQL Server :理解数据记录结构

    原文:SQL Server :理解数据记录结构 在SQL Server :理解数据页结构我们提到每条记录都有7 bytes的系统行开销,那这个7 bytes行开销到底是一个什么样的结构,我们一起来看下 ...

  8. redis配置密码认证

    redis配置密码 1.通过配置文件进行配置yum方式安装的redis配置文件通常在/etc/redis.conf中,打开配置文件找到 ? 1 #requirepass foobared 去掉行前的注 ...

  9. Hive JDBC:Permission denied&colon; user&equals;anonymous&comma; access&equals;EXECUTE&comma; inode&equals;”&sol;tmp”

    今天使用JDBC来操作Hive时,首先启动了hive远程服务模式:hiveserver2 &(表示后台运行),然后到eclipse中运行程序时出现错误: Permission denied: ...

  10. HDUOJ-----4506小明系列故事——师兄帮帮忙

    小明系列故事——师兄帮帮忙 Time Limit: 3000/1000 MS (Java/Others)    Memory Limit: 65535/32768 K (Java/Others)Tot ...