KVM Virtual machine snapshot chain creation, merging, deletion and rollback research

1 Qemu,kvm,libvirt Relationship QEMU

QEMU provides an open-source server full-virtualization solution that allows you to simulate other platform processors on a specific platform's physical machine, such as a virtual power CPU on a X86 CPU, where the guest OS does not feel the presence of a virtual machine, as if it were running on a physical machine, QEMU can use both an analog CPU and a variety of peripherals, as well as a user-space tool and a KVM running in the kernel to give full play to KVM functionality, and the QEMU wiki

Kvm

KVM is a kernel-based virtual machine (a loadable module in Linux) that implements full virtualization on the X86 platform of hardware-enabled virtualization (Intel Vt,amd-v), and because users cannot directly manipulate the kernel, it also requires a user space tool, a modified QEMU, This allows the user to use the KVM,QEMU to specifically provide command tools to operate the KVM

QEMU-IMG: A tool for Disk Management

qemu-system-x86_64, a command-line tool used to create a virtual machine for the x86 platform

Libvirt

Libvirt is an open source application interface, daemon, and management tool designed to more easily manage platform virtualization technology, which not only provides management of virtualized clients, but also provides management of virtualized networks and storage. Although the Libvirt project was originally designed as a set of APIs for Xen, the current support for other hypervisor such as KVM is also very good. Libvirt supports a variety of virtualization scenarios, supporting platform virtualization solutions including KVM, QEMU, Xen, VMware, VirtualBox, and other Linux container virtualization systems such as OPENVZ, LXC, etc. Also supports virtualization of user-configured Linux (UML).

Libvirt is essentially a package for different hypervisor commands, Libvirt provides API interfaces for different development languages, such as Python, C, etc. libvirtd is a daemon for Linux, To use Libvirt, you must first start the daemon

Because Libvirt is currently the most widely used tool and application interface (API) for managing KVM virtual machines, and some common virtual machine management tools such as Virsh, Virt-install, Virt-manager, etc.) and cloud computing framework platforms (such as OpenStack, Opennebula, eucalyptus, etc.) use Libvirt application interfaces on the ground floor

Libvirt as an intermediate adaptation layer, so that the underlying hypervisor to the upper user space management tools can be completely transparent, because libvirt shielding the underlying various hypervisor details, for the upper management tools to provide a unified, more stable interface (API)

For more information about this Libvirt

Put a picture below

2 Test Physical Environment 1 system version

Red Hat Enterprise Linux Server release 6.5 (Santiago)

2 libvirt && QEMU rpm version

[Email protected] scripts]# Rpm-qa | Egrep "(qemu|libvirt)" qemu-img-0.12.1.2-2.415.el6.3ceph.x86_64qemu-kvm-tools-0.12.1.2-2.415.el6.3ceph.x86_ 64libvirt-python-0.10.2-29.el6.x86_64gpxe-roms-qemu-0.9.7-6.10.el6.noarchlibvirt-0.10.2-29.el6.x86_ 64qemu-kvm-0.12.1.2-2.415.el6.3ceph.x86_64libvirt-client-0.10.2-29.el6.x86_64

3 About QEMU versions

RHEL6 on the default version of Qemu 0.12, it does not support the status of the Blockcommit, the latest version 2.1.2 can support, this section can refer to the changelog of the QEMU official website

Snapshot merge with boot status enabled

#qemu 1.3 Version Changelog:

A new Block job is supported:live Block commit (also known as "snapshot deletion") moves data from an image to another in The backing file chain. With the current implementation of QEMU 1.3, the "source" image is the active one.

Supports merging of current avtive snapshots

#qemu 2.0 Version Changelog

Live Snapshot Merge (...-commit) can be used to merge the active layer of a image into one of the snapshots

3. What is a virtual machine snapshot chain (snapshot chains)

Virtual machine Snapshots Save the state of a virtual machine at a specified point in time (including the operating system and all programs), taking advantage of the snapshot, we can restore the virtual machine to a previous state, such as testing the software often need to roll back the system

A snapshot chain is a chain of relationships that consists of multiple snapshots, which are arranged in a chain of creation time, like so, this article explains how to create this chain, the relationship between snapshots in the chain, shorten the chain, and how to use this link to roll back our virtual machine to a state

base-image<--guest1<--snap1<--snap2<--snap3<--snap4<--current (Active)

As above, Base-image is a production of a Qcow2 format disk image file, it contains a full OS and boot program, now with this base-image to create multiple virtual machines for the template, simple point method, every time we create a virtual machine we will copy this image intact, However, the efficiency of this approach is not enough to meet production needs, which is the use of qcow2 image characteristics Copy-on-write

Qcow2 (qemu copy-on-write) format mirroring supports snapshots with the ability to create a base-image and create multiple backing copy-on-write images on base-image (overlays file),

Explain the next backing file and overlay, in the chain above, we create a guest1 for Base-image, then Base-image is Guest1 file, Guest1 is Base-image overlay, in the same way, for guest1 virtual machine created a snapshot snap1, at this time Guest1 is snap1 of backing File,snap1 is Guest1 overlay,backing Files and overlays are useful for quickly creating thin equipment instances, especially during development testing that can be quickly rolled back to a previous state

As below, we have a centosbase original image (with full OS and bootstrapper) and now use it as a template to create multiple virtual machines, each of which can create multiple snapshots to form a snapshot chain, and of course cannot create snapshots for centosbase directly

.-----------.   .-----------.   .------------.  .------------.    .------------.    /------------\|           |   |           |   |            |  |            |    |            |    |            ||centosbase |<---  centos1  |<---centos1_sn1 <--- centos1_sn2 <--- centos1_sn3 |<-- |centos1_sn4 ||           |   |(overlays1)|   |            |  |            |    |            |    |  (Active)  |‘-----------‘   ‘-----------‘   ‘------------‘  ‘------------‘    ‘------------‘    \------------/   ^    ^   |    |   |    |       .-----------.    .------------.   |    |       |           |    |            |   |    ‘-------| centos2   |<---|centos2_sn1 |   ...   |            |(overlays2)|    |            |   |            ‘-----------‘    ‘------------‘   |   |   |            .-----------.    .------------.   |            |           |    |            |   ‘------------| centos3   |<---|centos3_sn1 |   ...                |(overlays3)|    |            |                ‘-----------‘    ‘------------‘

As with the CentOS system, we have created a virtual machine image in QCOW2 format that we want to use as a template to create multiple instances of virtual machines, and there are two ways to create instances
A. Each new instance, copy the Centosbase template and create a slow
B. Using Copy-on-write technology (features in QCOW2 format), create a template-based instance, create fast, and view disk File size comparison

CENTOS1,CENTOS2,CENTOS3 is a virtual machine (guest) created based on the Centosbase template, and the next test needs to be used, centos1_sn1,centos1_sn2,centos1_ SN3, etc. is the snapshot chain of the instance CENTOS1

We can create multiple virtual machine instances (overlays) with just one backing files, and then take multiple snapshots of each virtual machine instance

Note: Backing files is always read-only, in other words, once a new snapshot is created, his back-end files cannot be changed (snapshots are dependent on the backend state), refer to Blockcommit later to learn more

4. Creating a thin device instance (domain) for a virtual machine

Domain refers to a virtual machine created by Libvirt

QEMU-IMG is QEMU's Disk Management tool, which, after QEMU compiles, provides this tool by default, with the following chain of relationships

/-----<-[Centos1.qcow2] <-[Centos1_a.qcow2] <-[centos1_b.qcow2][(centosbase)]| \-----<-[Centos2.qcow2] <-[Centos2_a.qcow2] <-[Centos2_b.qcow2]

#使用模板镜像centosbase (backing file) to create two virtual machines (based on centosbase), 20G is not a required parameter qemu-img create-b centosbase.qcow2-f qcow2 Centos1.qcow2 20gqemu-img create-b centosbase.qcow2-f qcow2 centos2.qcow2 20G

Now created CENTOS1 and Centos2 can be used to start a virtual machine, because they rely on backing file, so the two disks are only hundreds of bytes in size, only the new files will be written to this disk

#查看镜像信息, including virtual disk size, actual footprint, backing fileqemu-img info centos1.qcow2

5. Built-in snapshot introduction (Internal snapshots) 5.1 Built-in disk snapshot

A single Qcow2 image file stores the disk state of the snapshot point, no new disk files are generated, the virtual machine run state and shutdown state can be created, and Libvirt uses the ' qemu-img ' command to create a disk snapshot of the shutdown state.

5.2 Built-in System restore points

Using the Virsh save/restore command
You can save the memory state, the device state and the disk status to a specified file in the virtual Machine boot state (memory), restore the virtual machine, and then restore back
Used in test scenarios, we often need to constantly restore the VMs to a starting point and then start the deployment and testing again.

6 External Snapshot Introduction (External snapshots) 6.1 external disk snapshot (External disk snapshot)

When a snapshot is created, the current state of the creation is saved in the currently used disk file, which becomes a backing file, at which point a new overlay is created to save the data written later

6.2 External System Restore points (External system checkpoint)

The virtual machine's disk status will be saved to a file, and the memory and device status will be saved to another new file

7. Built-in disk snapshot creation, rollback and deletion

Use CENTOS1 to test the internal disk snapshot operation (refer to section 3rd schematic)
#此虚拟机所使用磁盘为centos1. Qcow2, whose backing file is Centosbase.qcow2, allows you to observe the change in disk size during creation

#查看虚拟机信息qemu-img Info centos1.qcow2# Create snapshot 1 (centos1 runtime) Virsh snapshot-create-as centos1 centos1_sn1 centos1_sn1-desc# Create snapshot 2 (centos1 off) virsh shutdown Centos1virsh snapshot-create-as centos1 centos1_sn2 centos1_sn2-desc# View all snapshots Virsh Snapshot-list centos1name Creation time State------------------------------------------------------------centos1_ SN1 2014-12-09 16:16:23 +0800 runningcentos1_sn2 2014-12-09 16:18:38 +0800 shutoffcentos1_sn3 2014-12-09 16:19:59 +0800 sh Utoffcentos1_sn4 2014-12-09 16:21:22 +0800 running#running means creating a # Snapshot rollback when the virtual machine is turned on Virsh snapshot-revert--domain centos1 Centos1_sn1virsh Snapshot-revert--domain centos1 centos1_sn3# built-in disk snapshots can be rolled back, such as rolling back to SN1, rolling back to Sn3 is OK # Note that the virtual machine is turned on, Cannot roll back to the snapshot point of State running # snapshot Delete virsh snapshot-delete centos1 centos1_sn2 or Virsh snapshot-delete--domain centos1-- Snapshotname CENTOS1_SN2

8 External Disk Snapshot creation

To test an external disk snapshot using Centos2 this virtual machine (refer to section 3rd schematic)
The disk used by this virtual machine is centos2.qcow2 and the virtual machine is turned on

1. Start the Centos2 virtual machine first to view the disk currently in use

Virsh start Centos2virsh domblklist centos2target Source------------------------------------------------Vda/data_ LIJ/VHOSTS/CENTOS2.QCOW2HDC-

#可以看到, the disk currently in use is centos2.qcow2, as previously said, when an external disk snapshot is created, the disk being used as backing file is saved (this disk no longer accepts new data, only the data before the snapshot is saved), and create a new disk as overlays to wait for new data to be written

2. Create an external snapshot 1 (centos2 boot)

Virsh snapshot-create-as--domain centos2 centos2_sn1 centos2_sn1-desc--disk-only--diskspec vda,snapshot=external, File=/data_lij/vhosts/centos2_sn1.qcow2--atomic# View Snapshot virsh snapshot-list centos2# view Centos2 currently used disk Virsh Domblklist Centos2...vda/data_lij/vhosts/centos2_sn1.qcow2 ... #所使用磁盘已经更新到新创建的磁盘

3. View new disk Centos2_sn1.qcow2 information

Qemu-img info centos2_sn1.qcow2...backing file:/data_lij/vhosts/centos2.qcow2backing file Format:qcow2 ... #其backing File is the disk centos2.qcow2# snapshot used before the snapshot was created 2,3 (centos2 off) virsh snapshot-create-as--domain centos2 centos2_sn2 Centos2_sn2-desc --disk-only--diskspec Vda,snapshot=external,file=/data_lij/vhosts/centos2_sn2.qcow2--atomicvirsh Snapshot-create-as--domain centos2 centos2_sn3 centos2_sn3-desc--disk-only--diskspec vda,snapshot=external,file=/ Data_lij/vhosts/centos2_sn3.qcow2--atomic

4. View all external snapshots

Virsh snapshot-list centos2name Creation time State------------------------------------------------------------CENTOS2_SN1 2014-12-09 16:35:44 +0800 DISK-SNAPSHOTCENTOS2_SN2 2014-12-09 16:41:39 +0800 shutoffcentos2_sn3 2014-12-09 16:43:06 +0800 shutoffcentos2_sn4 2014-12-09 16:44:46 +0800 shutoff

5. View Current Disk usage

Virsh domblklist Centos2vda/data_lij/vhosts/centos2_sn4.qcow2

#虚拟机centos2使用的是最后一个快照的磁盘 (called active), it is important to understand that snapshots are interdependent (the previous dependency next), that each part holds data, and that all snapshots together hold all the data for the virtual machine

6. View the full snapshot chain of the virtual machine Centos2 (Centos2_sn4.qcow2 is currently using the disk)

Qemu-img Info--backing-chain centos2_sn4.qcow2

9. Merging of external disk snapshots 1. Merging methods

External snapshots are useful, but one problem here is how to combine snapshot files to shorten the length of a chain and not delete a snapshot directly because each snapshot holds the corresponding data
There are two ways of achieving
Blockcommit: Merging data from top to base (that is, merging overlays to backing files)
Blockpull: Merges the backing file data into the overlay. From base to top

2. Blockcommit down Merge

#blockcommit可以让你将 ' top ' image (in the same backing file chain) merged into the underlying ' base ' mirror, once Blockcommit #执行完成, The overlay chain relationship at the top is automatically directed to the underlying overlay or base, which is useful for shortening the length of the chain after creating a long chain.
#测试发现:
A qemu1.3 The following versions do not support live blockcommit,
B qemu2.0 The following versions do not support merging the ' Active ' layer (the topmost overlay, which is currently using disk) to Backing_files

#下面是

In this image above, we have 4 interdependent external disk snapshots that we previously created for the Centos2 virtual machine, representing the relationship

Current: [Base] <-sn1 <-sn2 <-sn3 <-sn4 (currently using disk)
Target: [Base] <-SN1 <---------------sn4

What we need to do is merge sn2,sn3 into SN1 and delete the Sn2,sn3 snapshot, the following two ways

(method-a): Virsh blockcommit--domain f17 vda--base/export/vmimages/sn1.qcow2--top/export/vmimages/sn3.qcow2--wait --verbose or (method-b): Virsh blockcommit--domain centos2 vda--base centos2_sn2.qcow2--top centos2_sn3.qcow2--wait-- Verbosevirsh blockcommit--domain centos2 vda--base centos2_sn1.qcow2--top centos2_sn2.qcow2--wait--verbose

Note: If the manual execution of the *qemu-img* command is complete, it is now only possible to use Method-b. We can also make centos2_sn4 (active) point directly to Centos2

3.blockpull merge up

The #blockpull (also known as ' Block Stream ' in Qemu) can merge backing into active, contrary to Blockcommit.
#在qemu最新版本2.1.2 On test discovery, only backing file can currently be merged into active use

Centosbase <--centos2 <--centos2_sn1 <--centos2_sn2 <--centos2_sn3 <--centos2_sn4 (active) #在上面快照链中, You can merge Sn1/sn2/sn3 to Sn4 (active), but you cannot merge sn1/sn2 to Sn3 because SN3 is not the current active disk

#下面是blockpull合并

With Blockpull We can merge the data in the CENTOS2_SN1/2/3 into the active layer, and eventually the Centos2 will become the direct backend of the active.

What we need to do is merge sn1,sn2,sn3 into Sn4 (active) and delete the Sn1,sn2,sn3 snapshot, which is the following representation of the relationship
Current: [Base (Centos2)] <-sn1 <-sn2 <-sn3 <-sn4 (currently using disk)
Target: [Base (Centos2)] <----------------------SN4

Virsh blockpull--domain centos_2--path/data_lij/vhosts/centos2_sn4.qcow2--base/data_lij/vhosts/centos2.qcow2-- Wait--verbose# clean off unused snapshots Virsh snapshot-delete--domain centos2 centos2_sn1--metadatavirsh snapshot-delete--domain Centos2 centos2_sn2--metadatavirsh snapshot-delete--domain centos2 centos2_sn3--metadata

#查看当前信息

#查看centos2的快照virsh snapshot-list centos2# View Centos2 currently using Disk Virsh domblklist centos2# view snapshot SN4 backing info Centos2_sn4.qcow2

#如果要迁移虚拟机centos2, you may want to merge all backing files into Centos2_sn4 (active) and then migrate Centos2_sn4 (active) to the destination

Centosbase <--centos2 <--centos2_sn1 <--centos2_sn2 <--centos2_sn3 <--centos2_sn4

Centosbase--Centos2---CENTOS2_SN1, CENTOS2_SN2---CENTOS2_SN3

#所有的backing files are merged into CENTOS2_SN4 (active) Virsh blockpull--domain centos2--path/data_lij/vhosts/centos2_sn4.qcow2-- Wait--verboseqemu-img info centos2_sn4.qcow2

#合并之后, CENTOS2_SN4 is a complete image, including all CENTOSBASE,SN1/2/3 data, which is no longer required backing files

10 removal of external snapshots (qemu-img commit/rebase) 1. Methods

We need to delete the snapshot SN2
Current: [Centosbase] <--centos2 <--centos2_sn1 <--centos2_sn2 <--centos2_sn3 <--centos2_sn4 (currently using disk)
Target: [centosbase] <--centos2 <--centos2_sn1 <------------------centos2_sn3 <--CENTOS2_SN4 (currently using disk)
Now delete the second snapshot (SN2). There are two ways:
(1): Copy SN2 data to backend SN1, will commit all SN2 data to SN2 backing file (SN1), and Virsh blockcommit similar
(2): Copy the SN2 data to the previous paragraph SN3, will commit all SN2 in the data to SN2 overlays, and Virsh blockpull similar
Note: SN1 must be guaranteed not to be a backend (i.e. CENTOS2_SN1 is only used by the current chain)

2. (1): Copy SN2 data to backend SN1

Qemu-img commit centos2_sn2.qcow2qemu-img Rebase-u-B centos2_sn1.qcow2 centos2_sn3.qcow2 #让sn3指向sn1

#现在sn1中包含了之前的sn1/SN2 data, so at this time no longer need the data in SN2, direct Sn3 point to SN1, you can directly delete SN2
Note:-U stands for ' Unsafe mode '--this mode only modifies the backing file name to which it is pointing (no data is copied)

3. (2): Copy SN2 data to the previous paragraph Sn3

Qemu-img rebase-b Centos2_sn1.qcow2 Centos2_sn3.qcow2

The rebase of the #未使用-u mode will also merge the data into the past, that is, the SN2 data is written to Sn3 and modified sn3 points to SN1, which is the default mode
#rebase是向前段合并, Commit is a back-end merge

This article refers to the online data to test, if there are errors please indicate, reprint please keep the link http://www.algoing.cn/2014/12/10/44/

Reference articles

http://itxx.sinaapp.com/blog/content/130

Https://kashyapc.fedorapeople.org/virt/lc-2012/snapshots-handout.html

KVM Virtual machine snapshot chain creation, merging, deletion and rollback research