Re: [libvirt] [PATCH] docs: Add detailed notes snapshots, blockcommit, blockpull

> + > +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

+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

> +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). ::

> + > + # rm sn2.qcow2 > + > This is a good article,I learned a lot from eblake and this article