For offline guests:
-------------------

If we have this image chain: base <- sn1 <- sn2 <- sn3
(arrow to be read as 'sn3 has sn2 as its backing file')

Let's assume we want to delete the second snapshot, that is, the
snapshot that for which sn2 was created. The goal is to end up with either of 
the below two chains:

(1) base <- sn1 <- sn3  (by copying sn2 into sn1)
(2) base <- sn1 <- sn3   (by copying sn2 into sn3)


For case (1)
------------
To end up with this: base <- sn1 <- sn3  (by copying sn2 into sn1)

NOTE: This is only possible *if* sn1 isn't used by more images as their backing file, or they'd get corrupted!!


(a) # qemu-img commit sn2 
	- this will 'commit' the changes from sn2 into its backing file(which is sn1)

(b) # qemu-img rebase -u -b sn1 sn3 
	- Changes the backing file link of sn3 to sn1 
		- NOTE: This is 'Unsafe mode' -- in this mode, only the backing file name is changed w/o any checks on the file contents. The user must take care of specifying the correct new backing file, or the guest-visible
			- This mode is useful for renaming or moving the backing file to somewhere else.  It can be used without an accessible old backing file, i.e. you can use it to fix an image whose backing file has already been moved/renamed.


(c) # rm sn2
	- remove the sn2 image



For case (2)
------------
To end up with this: base <- sn1 <- sn3  (by copying sn2 into sn3)

(a) # qemu-img rebase -b sn1 sn3  
	- Apart from changing backing file link of sn3 to sn1, the above cmd will it also /copy/ the contents from sn2 into sn3)
		- NOTE: This is 'Safe mode', which is the default -- any clusters that differ between backing_file and the old backing file of filename are merged into filename before actually changing the backing file. )

(b) # rm sn2
	- remove the sn2 image