Search
SupportConsoleDevelopersStart a trialContact

20.13. Working with Snapshots

download PDF

20.13.1. Shortening a Backing Chain by Copying the Data

This section demonstrates how to use the virsh blockcommit domain <path> [<bandwidth>] [<base>] [--shallow] [<top>] [--active] [--delete] [--wait] [--verbose] [--timeout <number>] [--pivot] [--keep-overlay] [--async] [--keep-relative] command to shorten a backing chain. The command has many options, which are listed in the help menu or man page.
The virsh blockcommit command copies data from one part of the chain down into a backing file, allowing you to pivot the rest of the chain in order to bypass the committed portions. For example, suppose this is the current state: 
      base ← snap1 ← snap2 ← active.
Using virsh blockcommit moves the contents of snap2 into snap1, allowing you to delete snap2 from the chain, making backups much quicker.

Procedure 20.1. How to shorten a backing chain

  • Enter the following command, replacing guest1 with the name of your guest virtual machine and disk1 with the name of your disk. 
    # virsh blockcommit guest1 disk1 --base snap1 --top snap2 --wait --verbose
    The contents of snap2 are moved into snap1, resulting in:
    base ← snap1 ← active. Snap2 is no longer valid and can be deleted

    Warning

    virsh blockcommit will corrupt any file that depends on the --base argument (other than files that depended on the --top argument, as those files now point to the base). To prevent this, do not commit changes into files shared by more than one guest. The --verbose option will allow the progress to be printed on the screen.

20.13.2. Shortening a Backing Chain by Flattening the Image

virsh blockpull can be used in in the following applications:
  1. Flattens an image by populating it with data from its backing image chain. This makes the image file self-contained so that it no longer depends on backing images and looks like this:
    • Before: base.img ← active
    • After: base.img is no longer used by the guest and Active contains all of the data.
  2. Flattens part of the backing image chain. This can be used to flatten snapshots into the top-level image and looks like this:
    • Before: base ← sn1 ←sn2 ← active
    • After: base.img ← active. Note that active now contains all data from sn1 and sn2, and neither sn1 nor sn2 are used by the guest.
  3. Moves the disk image to a new file system on the host. This is allows image files to be moved while the guest is running and looks like this:
    • Before (The original image file): /fs1/base.vm.img
    • After: /fs2/active.vm.qcow2 is now the new file system and /fs1/base.vm.img is no longer used.
  4. Useful in live migration with post-copy storage migration. The disk image is copied from the source host to the destination host after live migration completes.
    In short this is what happens: Before:/source-host/base.vm.img After:/destination-host/active.vm.qcow2./source-host/base.vm.img is no longer used.

Procedure 20.2. How to shorten a backing chain by flattening the data

  1. It may be helpful to create a snapshot prior to running virsh blockpull. To do so, use the virsh snapshot-create-as command. In the following example, replace guest1 with the name of your guest virtual machine, and snap1 with the name of your snapshot. 
    # virsh snapshot-create-as guest1 snap1 --disk-only
  2. If the chain looks like this: base ← snap1 ← snap2 ← active, enter the following command, replacing guest1 with the name of your guest virtual machine and path1 with the source path to your disk (/home/username/VirtualMachines/*, for example). 
    # virsh blockpull guest1 path1
    This command makes snap1 the backing file of active, by pulling data from snap2 into active resulting in: base ← snap1 ← active.
  3. Once the virsh blockpull is complete, the libvirt tracking of the snapshot that created the extra image in the chain is no longer useful. Delete the tracking on the outdated snapshot with this command, replacing guest1 with the name of your guest virtual machine and snap1 with the name of your snapshot. 
    # virsh snapshot-delete guest1 snap1 --metadata
Additional applications of virsh blockpull can be performed as follows:

Example 20.31. How to flatten a single image and populate it with data from its backing image chain

The following example flattens the vda virtual disk on guest guest1 and populates the image with data from its backing image chain, waiting for the populate action to be complete. 
# virsh blockpull guest1 vda --wait

Example 20.32. How to flatten part of the backing image chain

The following example flattens the vda virtual disk on guest guest1 based on the /path/to/base.img disk image. 
# virsh blockpull guest1 vda /path/to/base.img --base --wait

Example 20.33. How to move the disk image to a new file system on the host

To move the disk image to a new file system on the host, run the following two commands. In each command replace guest1 with the name of your guest virtual machine and disk1 with the name of your virtual disk. Change as well the XML file name and path to the location and name of the snapshot: 
# virsh snapshot-create guest1 --xmlfile /path/to/snap1.xml --disk-only
# virsh blockpull guest1 disk1 --wait

Example 20.34. How to use live migration with post-copy storage migration

To use live migration with post-copy storage migration enter the following commands:
On the destination enter the following command replacing the backing file with the name and location of the backing file on the host. 
# qemu-img create -f qcow2 -o backing_file=/source-host/vm.img /destination-host/vm.qcow2
On the source enter the following command, replacing guest1 with the name of your guest virtual machine: 
# virsh migrate guest1
On the destination, enter the following command, replacing guest1 with the name of your guest virtual machine and disk1 with the name of your virtual disk: 
# virsh blockpull guest1 disk1 --wait

20.13.3. Changing the Size of a Guest Virtual Machine's Block Device

The virsh blockresize command can be used to resize a block device of a guest virtual machine while the guest virtual machine is running, using the absolute path of the block device, which also corresponds to a unique target name (<target dev="name"/>) or source file (<source file="name"/>). This can be applied to one of the disk devices attached to guest virtual machine (you can use the command virsh domblklist to print a table showing the brief information of all block devices associated with a given guest virtual machine).

Note

Live image resizing will always resize the image, but may not immediately be picked up by guests. With recent guest kernels, the size of virtio-blk devices is automatically updated (older kernels require a guest reboot). With SCSI devices, it is required to manually trigger a re-scan in the guest with the command, echo > /sys/class/scsi_device/0:0:0:0/device/rescan. In addition, with IDE it is required to reboot the guest before it picks up the new size.

Example 20.35. How to resize the guest virtual machine block device

The following example resizes the guest1 virtual machine's block device to 90 bytes: 
# virsh blockresize guest1 90 B
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.