14.5.18. Disk Image Management with Live Block Copy
Live block copy is a feature that is not supported with the version of KVM that is supplied with Red Hat Enterprise Linux. Live block copy is available with the version of KVM that is supplied with Red Hat Virtualization. This version of KVM must be running on your physical host machine in order for the feature to be supported. Contact your representative at Red Hat for more details.
Live block copy allows you to copy an in use guest disk image to a destination image and switches the guest disk image to the destination guest image while the guest is running. Whilst live migration moves the memory and registry state of the host, the guest is kept in shared storage. Live block copy allows you to move the entire guest contents to another host on the fly while the guest is running. Live block copy may also be used for live migration without requiring permanent share storage. In this method the disk image is copied to the destination host after migration, but while the guest is running.
Live block copy is especially useful for the following applications:
- moving the guest image from local storage to a central location
- when maintenance is required, guests can be transferred to another location, with no loss of performance
- allows for management of guest images for speed and efficiency
- image format conversions can be done without having to shut down the guest
Example 14.1. Example using live block copy
This example shows what happens when live block copy is performed. The example has a backing file (base) that is shared between a source and destination. It also has two overlays (sn1 and sn2) that are only present on the source and must be copied.
- The backing file chain at the beginning looks like this:
base ← sn1 ← sn2The components are as follows:
- base - the original disk image
- sn1 - the first snapshot that was taken of the base disk image
- sn2 - the most current snapshot
- active - the copy of the disk
- When a copy of the image is created as a new image on top of sn2 the result is this:
base ← sn1 ← sn2 ← active
- At this point the read permissions are all in the correct order and are set automatically. To make sure write permissions are set properly, a mirror mechanism redirects all writes to both sn2 and active, so that sn2 and active read the same at any time (and this mirror mechanism is the essential difference between live block copy and image streaming).
- A background task that loops over all disk clusters is executed. For each cluster, there are the following possible cases and actions:
- The cluster is already allocated in active and there is nothing to do.
bdrv_is_allocated()to follow the backing file chain. If the cluster is read from base (which is shared) there is nothing to do.
bdrv_is_allocated()variant is not feasible, rebase the image and compare the read data with write data in base in order to decide if a copy is needed.
- In all other cases, copy the cluster into
- When the copy has completed, the backing file of active is switched to base (similar to rebase)
To reduce the length of a backing chain after a series of snapshots, the following commands are helpful:
blockpull. See Section 14.5.15, “Using blockcommit to Shorten a Backing Chain” for more information.