Analysis of snapshots in Linux and Blockcommit,blockpull

Basic knowledge
A virtual machine snapshot can be viewed as a view of a virtual machine at a given time (including his operating system and all programs).

As a result, one can revert to a previous complete state, or make a backup while the guest is running. So, in our

Before we go any further, we must understand two nouns: backing files and overlays.

QCOW2 backing files and overlays
Qcow2 (Qemu copy-on-write) has the creation of a base-image, as well as in base-image (that is, backing file)

The ability to create multiple copy-on-write overlays mirrors based on the. backing files and overlays are very useful,

You can quickly create an instance of a thin-gear virtual machine, especially if you are developing a test that allows you to quickly roll back to a previous

Known state, discard overlay.

Figure-1

.--------------.    -------------.    -------------.    ------ -------.
|              |    |              |    |              |    |              |
| rootbase     |<---| overlay-1   |<---| overlay-1a  <---| overlay-1b  |
| (raw/qcow2)   |    | (qcow2)      |    | (qcow2)      |    | (qcow2)      |
'--------------'     '-------------'     '-------------'     '----- --------'
The figure above indicates that Rootbase is Overlay-1 's backing file, and so on.

Figure-2

.-----------.   .-----------.  .------------.  .------------. .------------.


|   |           |   |            |  |            |  |            | |


| Rootbase |&lt;---Overlay-1 |&lt;---overlay-1a &lt;---overlay-1b &lt;---overlay-1c |


|   |           |   |            |  |            |  | | (Active) |


'-----------'   '-----------'   '------------'  '------------'  '------------'


^    ^


| |


|       |    .-----------. .------------.


|       |           |    |            | |


| '-------| Overlay-2 |&lt;---| overlay-2a |


|           |    | | (Active) |


| '-----------'    '------------'


|


|


|    .-----------. .------------.


|           |    |            | |


'------------| Overlay-3 |&lt;---| overlay-3a |


|    | | (Active) |


'-----------'    '------------'


The above illustration shows that we can create more than one chain with a single backing file.

Note: Backing file is always read-only open. In other words, once a new snapshot is created,

His back-end files cannot be modified (the snapshot relies on this state of the backend file).

See the following (' Blockcommit ' section) for more information.

Example:

[FEDORABASE.IMG]-----<-[Fed-guest-1.qcow2] <-[Fed-w-updates.qcow2] <-[FEDORA-GUEST-WITH-UPDATES-1A]

---<-[fed-guest-2.qcow2] <-[Fed-w-updates.qcow2] <-[FEDORA-GUEST-WITH-UPDATES-2A]
(Note the direction of the arrow, Fed-w-updates.qcow2 backing file is Fed-guest-1.qcow2)

As you can see in the example above, Fedorabase.img installs a fedora17 system and acts as our backing file.

Now this backing file will be used as a template to quickly create two examples of thin equipment, and Figure-2 is the same reason.

Use QEMU-IMG for a single backing file to create two fedora clones of thin equipment:

# qemu-img Create-b/export/vmimages/rootbase.img-f Qcow2
/export/vmimages/fedora-guest-1.qcow2
# qemu-img Create-b/export/vmimages/rootbase.img-f Qcow2
/export/vmimages/fedora-guest-2.qcow2
Now, the two mirrored fedora-guest-1 & Fedora-guest-2 created above can be used to

Start a virtual machine and continue with our example, now we need to create a F17 instance, but this time we need

Creates an instance with a complete update, you can create another overlay (FEDORA-GUEST-WITH-UPDATES-1A)

And this overlay backing file is ' Fed-w-updates.qcow2 ' (a mirror that contains a full update):

# qemu-img Create-b/export/vmimages/fed-w-updates.qcow2-f Qcow2
/export/vmimages/fedora-guest-with-updates-1a.qcow2
We can use the QEMU-IMG command to view mirrored information, including the virtual disk size, use size, backing file point to:

# qemu-img Info/export/vmimages/fedora-guest-with-updates-1a.qcow2
Note: The latest version of QEMU-IMG can be recursively queried to complete the entire chain:

# qemu-img Info--backing-chain/export/vmimages/fedora-guest-with-updates-1a.qcow2
noun Interpretation Snapshot:
Built-in snapshots (Internal snapshots)--a single Qcow2 mirrored file stores state information including data and snapshots.

The built-in snapshots can also be subdivided:-

Internal disk snapshots (Internal disk snapshot):

The disk status of the snapshot point, data, and snapshots are kept in a single qcow2 file, and the virtual machine running status and shutdown state are

can be created.

Libvirt uses the ' qemu-img ' command to create a disk snapshot of the shutdown state.
Libvirt uses the ' SAVEVM ' command to create a disk snapshot of the running state.
Built-in System Restore point (Internal system checkpoint):

Memory status, device state, and disk status can be created for running virtual machines, all information stored in

In the same Qcow2 file, the built-in System restore point can only be created in the running state.

Libvirt use the ' SAVEVM ' command to create this snapshot
External snapshots (External snapshots)--When a snapshot is created, the current state of the creation is saved in the current use

In the disk file, that becomes a backing file.

At this point a new overlay is created to save the data in the future.

This can also be subdivided:-

External disk snapshots (External disk snapshot):

A snapshot of the disk is saved in a file, and the data after the creation of the Point-in-time is recorded in a new Qcow2 file.

Can also be created in the run and shutdown state.

Libvirt uses the ' Transaction ' command to create this snapshot for the running state.
Libvirt uses the ' qemu-img ' command to create this snapshot for the shutdown state (up to the present feature is still under development).
External System Restore point (External system checkpoint):

The disk status of the virtual machine will be saved to a file, and the state of the memory and device will be saved to another new file.

(This feature is also under development).

VM Status (VM State):

Save the state of the running state virtual machine memory device status information to the file, you can restore through this file to the state of the save, a bit like the system

of hibernation. (Note that when creating a VM state save, the VM disk must be write-not-changed)

Libvirt uses the ' migrate ' (to file) command to complete a VM state dump.
Create snapshots
Each time an external snapshot is generated, a/new/overlay mirror is generated, and the previous mirror becomes a snapshot.

Diskonly Built-in Snapshot creation

If you need to create a built-in snapshot of a running state or a closed state for a virtual machine named ' F17vm1 SNAP1

# Virsh Snapshot-create-as f17vm1 snap1 Snap1-desc
List the snapshots, use *qemu-img* to view info

# Virsh Snapshot-list f17vm1
# qemu-img Info/home/kashyap/vmimages/f17vm1.qcow2
Disk-only External Snapshot creation:

To view a list of virtual machine disks

# Virsh Domblklist f17-base
Target Source
---------------------------------------------
Vda/export/vmimages/f17-base.qcow2
#
Create an external disk-only disk snapshot (vm* running state *):

# Virsh Snapshot-create-as--domain f17-base snap1 Snap1-desc
--disk-only--diskspec Vda,snapshot=external,file=/export/vmimages/sn1-of-f17-base.qcow2
--atomic
Domain Snapshot Snap1 created
#
* Once the above command is executed, the original mirror f17-base becomes backing file, and a new mirror is created.
Now that the list looks at the virtual machine disk, you will find that the newly generated mirror is already in use.

# Virsh Domblklist f17-base
Target Source
----------------------------------------------------
Vda/export/vmimages/sn1-of-f17-base.qcow2
#
Snapshot rollback
By the time this article is written, rolling back to ' built-in snapshots ' (System checkpoint or Disk-only) is available.

Virtual machine f17vm1 rollback to snapshot ' snap1 '

# Virsh Snapshot-revert--domain f17vm1 snap1
Using Snapshot-revert to rollback ' external disk snapshots ' is a little more complicated and involves a slightly more complex problem,

Consider whether to merge ' base ' to ' top ' or merge ' top ' to ' base '.

In other words, there are two ways to choose, and the shortening of the external disk snapshot chain can be used Blockpull or blockcommit.

The upstream community is still trying to perfect this function.

Merging snapshot files
External snapshots are useful, but here's the question of how to combine snapshot files to shorten the length of a chain, as described here

There are two ways of doing this:

Blockcommit: Merges data from top to base (that is, merge overlays to backing files).
Blockpull: Merges backing file data into overlay. From base to top.
Blockcommit
Blockcommit allows you to merge the ' top ' mirrors (in the same backing file chain) into the underlying ' base ' mirror image.

Once the Blockcommit execution completes, the overlay chain relationship at the top will be directed to the underlying overlay or base.

This is useful when a long chain is created to shorten the chain length.

Here's a diagram to illustrate the following:

We now have a mirror called ' Rootbase ', with 4 external snapshots, ' Active ' writing data for the current VM,

Using ' Blockcommit ' can have the following kinds of case:

Merging Snap-1, Snap-2 and Snap-3 to ' rootbase '
Merge Snap-1 and Snap-2 to Rootbase only
Merge Snap-1 to Rootbase only
Merging Snap-2 to Snap-1
Merging Snap-3 to Snap-2
Merging Snap-2 and Snap-3 to Snap-1
Note: The ability to merge the ' Active ' layer (top overlay) to Backing_files is still under development.

(The following illustration explains case (6))

Figure-3

.------------.  .------------.  .------------.  .------------. .------------.


|  |            |  |            |  |            |  |            | |


| Rootbase &lt;---Snap-1 &lt;---Snap-2 &lt;---Snap-3 &lt;---Snap-4 |


|  |            |  |            |  |            |  | | (Active) |


'------------'  '------------'  '------------'  '------------'  '------------'


/                  |


/                   |


/Commit Data |


/                     |


/                      |


/                       |


V Commit Data |


.------------. .------------. &lt;--------------------'.------------.


|  |            |                                  |            | |


|  Rootbase &lt;---Snap-1 |&lt;---------------------------------| Snap-4 |


|  |            |       | backing File | (Active) |


'------------'  '------------'                                  '------------'


For example, there are the following scenarios:

Current: [Base] <-sn1 <-sn2 <-sn3 <-sn4 (This is active)

Target: [base] <-SN1 <-sn4 (so to discard Sn2,sn3)

There are two ways to method-a faster, method-b slower, but SN2 is available. (VM running state).

(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 f17 VDA--base/export/vmimages/sn2.qcow2
--top/export/vmimages/sn3.qcow2--wait--verbose
# Virsh Blockcommit--domain f17 VDA--base/export/vmimages/sn1.qcow2
--top/export/vmimages/sn2.qcow2--wait--verbose

Note: If you perform the *qemu-img* command manually, you can only use Method-b now.
Figure-4

.------------.  .------------.  .------------.  .------------. .------------.


|  |            |  |            |  |            |  |            | |


| Rootbase &lt;---Snap-1 &lt;---Snap-2 &lt;---Snap-3 &lt;---Snap-4 |


|  |            |  |            |  |            |  | | (Active) |


'------------'  '------------'  '------------'  '------------'  '------------'


/                  | |


/                   | |


/                    | |


Commit Data/commit Data | |


/                      | |


/                       | Commit Data |


V | |


.------------. &lt;----------------------|-------------'.------------.


|            |&lt;----------------------' | |


|                                                  Rootbase |  | Snap-4 |


| |&lt;-------------------------------------------------| (Active) |


'------------' backing File '------------'


The figure above illustrates the blockcommit direction of Case1, and now Sn4 's backing file points to rootbase.

Blockpull
Blockpull (also known as ' Block Stream ' in Qemu) can merge backing into active, just as opposed to blockcommit.

Only backing file can now be merged into the currently used active, meaning that the merge for the specified top is not yet supported.

Imagine one of the following scenarios:

Figure-5

.------------.  .------------.  .------------.  .------------. .------------.


|  |            |  |            |  |            |  |            | |


| Rootbase &lt;---Snap-1 &lt;---Snap-2 &lt;---Snap-3 &lt;---Snap-4 |


|  |            |  |            |  |            |  | | (Active) |


'------------'  '------------'  '------------'  '------------'  '------------'


| |


| |


| |


|                 | Stream data


| | Stream data


| Stream Data |


|                    | V


.------------.                 | '---------------&gt;------------.


|      |            '---------------------------------&gt; | |


|                                           Rootbase |  | Snap-4 |


| | &lt;----------------------------------------| (Active) |


'------------' backing File '------------'


With Blockpull We can merge the data from the SNAP-1/2/3 into the active layer, and eventually the Rootbase will become an active direct backend.

The order is as follows:

Suppose the snapshot has been completed using the method created in the Snapshots section:

As described in *figure-5*-[rootbase] <-[Active].

# Virsh Blockpull--domain rootbase
--path/var/lib/libvirt/images/active.qcow2
--base/var/lib/libvirt/images/rootbase.qcow2
--wait--verbose
The next task is that we need to use Virsh to clean out the unused snapshots.

# Virsh Snapshot-delete--domain rootbase Snap-3--metadata
# Virsh Snapshot-delete--domain rootbase Snap-2--metadata
# Virsh Snapshot-delete--domain rootbase Snap-1--metadata
Figure-6

.------------.  .------------.  .------------.  .------------. .------------.


|  |            |  |            |  |            |  |            | |


| Rootbase &lt;---Snap-1 &lt;---Snap-2 &lt;---Snap-3 &lt;---Snap-4 |


|  |            |  |            |  |            |  | | (Active) |


'------------'  '------------'  '------------'  '------------'  '------------'


|              | |


|              | |


|              |                      | Stream data


|              | | Stream data


|              | |


| | Stream Data |


|              Stream Data | '------------------&gt; V


|                                    | .--------------.


|              '---------------------------------&gt; | |


|  | Snap-4 |


'----------------------------------------------------&gt; | (Active) |


'--------------'


' Standalone '


(w/o backing


File


The figure above shows that all backing file is merged into active

Execute the command as follows:


(1) Before we perform the merge * Check the size of the snapshot (watch for ' Active '):


::


# ls-lash/var/lib/libvirt/images/rootbase.img


608m-rw-r--r--. 1 qemu qemu 1.0G Oct one 17:54/var/lib/libvirt/images/rootbase.img


# ls-lash/var/lib/libvirt/images/*snap*


840K-RW-------. 1 qemu qemu 896K Oct one 17:56/var/lib/libvirt/images/snap-1.qcow2


392K-RW-------. 1 qemu qemu 448K Oct one 17:56/var/lib/libvirt/images/snap-2.qcow2


456K-RW-------. 1 qemu qemu 512K Oct one 17:56/var/lib/libvirt/images/snap-3.qcow2


2.9M-RW-------. 1 qemu qemu 3.0M Oct one 18:10/var/lib/libvirt/images/active.qcow2


(2) Individually check the backing file that the ' Active ' points to:


# qemu-img Info/var/lib/libvirt/images/active.qcow2


Image:/var/lib/libvirt/images/active.qcow2


File Format:qcow2


Virtual size:1.0g (1073741824 bytes)


Disk Size:2.9m


cluster_size:65536


Backing file:/var/lib/libvirt/images/snap-3.qcow2


(3) Start **blockpull** operation.


::


# Virsh Blockpull--domain ptest2-base--path/var/lib/libvirt/images/active.qcow2--wait--verbose


Block Pull: [100%]


Pull Complete


(4) Again check the size of the snapshot, ' Active ' becomes very large


::


# ls-lash/var/lib/libvirt/images/*snap*


840K-RW-------. 1 qemu qemu 896K Oct one 17:56/var/lib/libvirt/images/snap-1.qcow2


392K-RW-------. 1 qemu qemu 448K Oct one 17:56/var/lib/libvirt/images/snap-2.qcow2


456K-RW-------. 1 qemu qemu 512K Oct one 17:56/var/lib/libvirt/images/snap-3.qcow2


1011M-RW-------. 1 qemu qemu 3.0M Oct one 18:29/var/lib/libvirt/images/active.qcow2


(5) Check ' Active ' information, now it does not need backing file, as shown in *figure-6*:


# qemu-img Info/var/lib/libvirt/images/active.qcow2


Image:/var/lib/libvirt/images/active.qcow2


File Format:qcow2


Virtual size:1.0g (1073741824 bytes)


Disk size:1.0g


cluster_size:65536


(6) Clean up the scene


::


# Virsh Snapshot-delete--domain rootbase Snap-3--metadata


(7) You can now also use the Guestfish **read-only** mode to check the contents of the disk (*--ro* option)


::


# guestfish--ro-i-a/var/lib/libvirt/images/active.qcow2


Snapshot deletion (and ' offline commit ')


Delete (Live/offline) state of the * built-in snapshot * is very convenient::


# Virsh Snapshot-delete--domain f17vm--snapshotname snap6

[OR]

# Virsh Snapshot-delete F17VM SNAP6

Libvirt has not yet removed the ability to remove external snapshots, but it can be done using the *qemu-img* command.

For example, we have such a chain (vm*offline* State): Base <-sn1 <-SN2 <-

Now delete the second snapshot (SN2). There are two ways:

Method (1): Base <-SN1 <-sn3 (by copying SN2 into SN1)
Method (2): Base <-SN1 <-sn3 (by copying SN2 into SN3)
Method (1)
(by copying SN2 into SN1)

Note: You must ensure that SN1 is not the other snapshots as the back end, or hang!!

Offline commit

# qemu-img Commit Sn2.qcow2
All changes in SN2 to SN2 backing file (SN1) will be *commit*.
Qemu-img Commit and Virsh blockcommit similar
Now point the back end of the sn3 to the SN1.

# qemu-img Rebase-u-B sn1.qcow2 sn3.qcow2
Note:-u represents ' Unsafe mode '--this mode only modifies the backing file name to which it is directed, and must be carefully manipulated.
You can now delete SN2 directly

# RM Sn2.qcow2
Method (2)
(by copying SN2 into SN3)

Merging data, rebase back end:

# qemu-img Rebase-b Sn1.qcow2 Sn3.qcow2
Rebase, which does not use the-u mode, merges the data together, that is, the SN2 data is written to the SN3.
In other words: the ' Safe mode ' used here is also the default mode--for SN3 any
The Qemu-img rebase (no-u) is similar to the Virsh blockpull.
Variance changes between Backingfile (SN1) to the old Backingfile (SN2) will be merged into SN3.

Now you can delete the SN2.

# RM Sn2.qcow2