Kvm+libvirt virtual machine snapshot [go]

Brief analysis of snapshots, blockcommit,blockpull

Kashyap Chamarthy <kchamart#redhat.com>

Date:tue, Oct 2012 15:28:06 +0530

This is an introduction to snapshots, Blockpull, Blockcommit. Author and with Eric Blake, Jeff Cody,kevin Wolf and many IRC and mailing Lists the students in a lot of discussion and the author of a large number of special tests based on the summary of

The author is also preparing to write some documents about the BlockCopy section, but this will be done after he finishes the BlockCopy test.

The author welcomes comments Welcome to shoot bricks. (I also welcome)

• ---

• Docs/snapshots-blockcommit-blockpull.rst

• .. --------------------------------------------------------------

• Note: All tests are Daoteng on the latest qemu-git,libvirt-git (as of 20-oct-2012 on the Fedora-18 Alpha system

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

Basic knowledge

A virtual machine snapshot can be viewed as a virtual machine's view at a specified time (including his operating system and all programs). As a result, one can revert to a previous complete state, or make a backup when the guest is running. So before we go any further, we have to understand two noun: backing Files and overlays.

QCOW2 backing files and overlays

Qcow2 (Qemu copy-on-write) has the ability to create a base-image and create multiple backing Copy-on-write images based on the base-image (that is, the overlays file). backing Files and overlays are useful for quickly creating instances of a thin-equipment virtual machine, especially when developing tests that allow you to quickly roll back to a previously known state and discard overlay.

Figure-1

Indicates that Rootbase is a backing file for Overlay-1, and so on.

Figure-2

Indicates that we can create multiple chains with only a single backing file.

Note : Backing file is always read-only open. In other words, once a new snapshot is created, his back-end file cannot be modified (the snapshot depends on the state of the backend file). Learn more at the back (' Blockcommit ' section).

XX: In other words, only the files in the middle of the chain become read-only open? 】

Example :

(Note the direction of the arrows, 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 the Figure-2 truth is the same.

Use qemu-img to create a thin device clone of two fedora for a single backing file:

# qemu-img Create-b/export/vmimages/rootbase.img-f qcow2/export/vmimages/fedora-guest-1.qcow2# qemu-img create-b/E Xport/vmimages/rootbase.img-f Qcow2/export/vmimages/fedora-guest-2.qcow2

Now, the two images created above Fedora-guest-1 & Fedora-guest-2 can be used to start a virtual machine, continue our example, now we need to create an instance of F17, but this time we need to create an instance with a full update, You can then create another overlay (FEDORA-GUEST-WITH-UPDATES-1A).

And this overlay backing file is ' Fed-w-updates.qcow2 ' (a mirror that contains the 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 the mirrored information, including the virtual disk size, size, backing file point:

# qemu-img Info/export/vmimages/fedora-guest-with-updates-1a.qcow2

Note: The latest version of Qemu-img can be queried recursively into the entire chain:

# qemu-img Info--backing-chain/export/vmimages/fedora-guest-with-updates-1a.qcow2

Noun explanation Snapshot:

• built-in snapshots (Internal snapshots) --a single qcow2 image file stores state information including data and snapshots.

  Built-in snapshots can also be subdivided:-

  • Libvirt use the ' SAVEVM ' command to create this snapshot

  • Libvirt uses the ' qemu-img ' command to create a disk snapshot of the shutdown state.

  • Libvirt use the ' SAVEVM ' command to create a disk snapshot of the running state.

1. built-in disk snapshots (Internal disks snapshot):

   The disk state of the snapshot point, data and snapshots are saved in a single qcow2 file, and the virtual machine run state and shutdown state can be created.

2. built-in System Restore point (Internal systems checkpoint):

   Memory state, device state, and disk status, can be created for a running virtual machine, all information is stored in the same Qcow2 file, and the built-in System Restore point is created only in a running state.

• external Snapshot (External snapshots) -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 this point a new overlay is created to save the data in the future.

This can also be subdivided:-

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 off state (as of now the feature is still under development).

1. Snapshots for external disks (External disk snapshot):

   A snapshot of the disk is saved in a file, and the data that is created at the point in time is recorded in a new Qcow2 file. The same can be created in the run and shutdown states.

2. External Systems restore point (External system checkpoint):

   The disk status of the virtual machine will be saved to a file, and the memory and device status will be saved to another new file (this feature is also in development).

VM status (VM State):

Saves the memory device state information of the running state virtual machine to the file, which can be restored to the saved state, a bit similar to the hibernation of the system. (Note that VM disks must not have write changes when creating VM State Save)

• Libvirt uses the ' migrate ' (to file) command to complete the VM State dump.

Create snapshots

• Each time an external snapshot is generated, a/new/overlay image is generated, and the previous image becomes a snapshot.

• Diskonly built-in snapshot creation

1. 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

2. List snapshot lists and use *qemu-img* to view info

   # Virsh snapshot-list f17vm1# qemu-img info/home/kashyap/vmimages/f17vm1.qcow2

• disk-only External Snapshot creation :

2. View a list of virtual machine disks

   # Virsh domblklist f17-basetarget Source---------------------------------------------vda/export/vmimages/f17-b Ase.qcow2

4. 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--atomicdomain Snapshot snap1 created# * Once the above command is executed, the original image f17-base will become backing file, A new image is created.

6. Now look at the virtual machine disk again, and you will see that the newly created image has been put into use.

   # Virsh domblklist f17-basetarget Source----------------------------------------------------vda/export/vmimage S/sn1-of-f17-base.qcow2

Snapshot rollback

When writing this article, rollback 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 roll back ' external disk snapshots ' is a bit more complicated and involves a slightly more complex point, with the need to consider merging ' base ' to ' top ' or merging ' top ' to ' base '.

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

Up to now the upstream community is still working to improve this function.

Merging snapshot files

External snapshots are useful, but here's a question of how to combine snapshot files to shorten the length of the 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 the backing file data into the overlay. From base to top .

Blockcommit

Blockcommit allows you to merge the ' top ' image (in the same backing file chain) into the underlying ' base ' image.

Once the blockcommit execution is complete, the overlay link at the top will be directed to the underlying overlay or base.

This is useful for shortening the length of a chain after creating a long chain.

Below is a diagram to illustrate the following:

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

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

1. Merge Snap-1, Snap-2 and Snap-3 to ' rootbase '

2. Merge only Snap-1 and Snap-2 to Rootbase

3. Merge Snap-1 to Rootbase only

4. Merge Snap-2 to Snap-1

5. Merge Snap-3 to Snap-2

6. 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.

(Explanation case (6))

Figure-3

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 effectively. (VM Run 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 the manual execution of the *qemu-img* command is complete, it is now only possible to use Method-b.

Figure-4

Demonstrates the blockcommit trend of case1, and now SN4 backing file points to rootbase.

Blockpull

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

As of now, only backing file can be merged into the currently used active, which means that the merge of the specified top is not supported.

Imagine one of the following scenarios:

Figure-5

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

The command is as follows:

1. Assume that the snapshot was already done using the Create snapshots subsection:

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

   # Virsh Blockpull--domain rootbase--path/var/lib/libvirt/images/active.qcow2--BASE/VAR/LIB/LIBVIRT/IMAGES/ROOTB Ase.qcow2--wait--verbose

The next job is that we need to use Virsh to clean up unused snapshots.

# Virsh Snapshot-delete--domain rootbase Snap-3--metadata# virsh snapshot-delete--domain rootbase Snap-2--metadata# VI Rsh snapshot-delete--domain rootbase Snap-1--metadata

Figure-6

The

represents all backing file merges into active

Execute the following command: (1)   *  look at the size of the snapshot before we perform the merge  * (watch ' Active '):    ::         # ls -lash /var/lib/libvirt/images/RootBase.img         608m -rw-r--r--.  1 qemu qemu 1.0g oct 11  17:54 /var/lib/libvirt/images/rootbase.img        # ls  -lash /var/lib/libvirt/images/*snap*        840k - RW-------.  1 qemu qemu 896k oct 11 17:56 /var/lib/libvirt/images/ SNAP-1.QCOW2        392K -RW-------.  1 qemu qemu  448K Oct 11 17:56 /var/lib/libvirt/images/Snap-2.qcow2         456K -RW-------.  1 qemu qemu 512K Oct 11 17:56  /var/lib/libvirt/images/snap-3.QCOW2        2.9M -RW-------.  1 qemu qemu  3.0m oct 11 18:10 /var/lib/libvirt/images/active.qcow2 (2)   separate check under   ' Active '   The point of the backing file ::        # 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)   Re-check the snapshot size,  ' Active ' Become very big     ::        # ls -lash /var/ LIB/LIBVIRT/IMAGES/*SNAP*         840K -RW-------.  1  qemu qemu 896K Oct 11 17:56 /var/lib/libvirt/images/Snap-1.qcow2          392K -RW-------.  1 qemu qemu 448k  Oct 11 17:56 /var/lib/libvirt/images/Snap-2.qcow2          456K -RW-------.  1 qemu qemu 512K Oct 11 17:56  /var/lib/libvirt/images/snap-3.qcOW2        1011M -RW-------.  1 qemu qemu 3.0m  oct 11 18:29 /var/lib/libvirt/images/active.qcow2 (5)   Check ' Active ' information, now it doesn't 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)   cleanup site     ::         # virsh snapshot-delete --domain rootbase snap-3 --metadata (7)   Now you can also use the next  guestfish  **read-only**   mode to check the contents of the disk ( *--ro*  options)     ::         # guestfish --ro -i -a /var/lib/libvirt/images/active.qcow2

Snapshot deletion (and ' offline commit ')

• The Delete (live/offline) status of the * built-in snapshot * is convenient:

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

  [OR]

  # Virsh Snapshot-delete F17VM SNAP6

Libvirt does not yet have the ability to delete 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 <-sn3

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 to SN1)

Note : You must ensure that the SN1 is not being used as the backend, or else it will hang!!

1. Offline commit

   # qemu-img Commit Sn2.qcow2

• Will *commit* all changes in SN2 to SN2 's backing file (SN1).

• 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 stands for ' Unsafe mode '--this mode only modifies the backing file name pointed to, and must be handled with caution.

You can now delete SN2 directly

# RM Sn2.qcow2

Method (2)

(by copying SN2 to SN3)

1. Merging data, rebase back end:

   # qemu-img Rebase-b Sn1.qcow2 Sn3.qcow2

   The difference between backingfile (SN1) and the old Backingfile (SN2) will be merged into SN3.

• Rebase that do not use the-u mode will also merge the data in the past, i.e. SN2 data is written to SN3.

• In other words: the ' Safe mode ' used here is also the default mode--for SN3, any

• Qemu-img rebase (no-u) and similar to Virsh blockpull.

Now you can delete SN2.

# RM Sn2.qcow2

--------------------------------------------------------------------

Kvm+libvirt virtual machine snapshot [go]