> +
> +The above figure is another representation of reducing the disk image chain
> +using blockcommit. Data from Snap-1, Snap-2, Snap-3 are merged(/committed)
> +into RootBase, & now the current 'Active' image now pointing to 'RootBase' as its
> +backing file(instead of Snap-3, which was the case *before* blockcommit). Note
> +that, now intermediate images Snap-1, Snap-1, Snap-3 will be invalidated(as they were
......................................................Snap-1,Snap-2,........
> +dependent on a particular state of RootBase).
> +
> +blockpull
....................................................................
> +**Figure-5**
> +::
> +
> + .------------. .------------. .------------. .------------. .------------.
> + | | | | | | | | | |
> + | RootBase <--- Snap-1 <--- Snap-2 <--- Snap-3 <--- Snap-4 |
> + | | | | | | | | | (Active) |
> + '------------' '------------' '------------' '------------' '------------'
> + | | \
> + | | \
> + | | \
> + | | \ stream data
> + | | stream data \
> + | stream data | \
> + | | v
> + .------------. | '---------------> .------------.
> + | | '---------------------------------> | |
> + | RootBase | | Snap-4 |
> + | | <---------------------------------------- | (Active) |
> + '------------' Backing File '------------'
> +
> +
> +
> +The above figure illustrates that, using block-copy we can pull data from
.......................................................using blockpull .................................
> +Snap-1, Snap-2 and Snap-3 into the 'Active' layer, resulting in 'RootBase'
> +becoming the backing file for the 'Active' image (instead of 'Snap-3', which was
> +the case before doing the blockpull operation).
--------------------------------------------------------------------------------------------------------------
> +
> +
> +Method (2)
> +----------
> +To end up with this image chain : **base <- sn1 <- sn3** (by copying *sn2* into *sn3*)
> +
> + (a) Copy contents of sn2(the old backing file) into sn3, and change the backing file link of sn3 to sn1::
> +
> + # qemu-img rebase -b sn1.qcow2 sn3.qcow2
> +
> + - Apart from changing backing file link of sn3 to sn1, the above cmd
> + will it also /copy/ the contents from sn2 into sn3).
> +
> + - In other words: This is 'Safe mode', which is the default --
> + any clusters that differ between the new backing_file(in this
> + case, sn1) and the old backing file(in this case, sn2) of
> + filename(in this case, sn3) are merged into filename(sn3), before
> + actually changing the backing file.
> +
> + (b) Now, we can delete the sn2 disk image(as the changes are now committed to
> + sn1). ::
...........................................................(as the changes are now merged into sn3).......
> +
> + # rm sn2.qcow2
> +
>
This is a good article,I learned a lot from eblake and this article ,thanks all!
I've translated it into Chinese (http://goo.gl/9xzql) to get more people join us.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list