14.5.18. Disk Image Management with Live Block Copy
- 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
- 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)
blockpull. See Section 14.5.15, “Using blockcommit to Shorten a Backing Chain” for more information.