[libvirt] Re: RFC: API additions for enhanced snapshot support

[Nicolas Sebrecht]

The 05/07/11, Eric Blake wrote:

> or, to merge all of base.img into snapshot.qcow2 then change
> snapshot.qcow2 to no longer have a backing file, before deleting base.img.
> 
> As I understand it, either file can be deleted when a snapshot is no
> longer needed, but having the flexibility to decide which of the two
> files to delete would be useful, and may require knowing how dirty the
> snapshot file is in relation to the original file (if it is 95% dirty,
> it is faster to just pull in the last few blocks from base into snapshot
> before deleting base, whereas if it is only 5% dirty, it is faster to
> sync the dirtied blocks from snapshot back to base before deleting
> snapshot).  And even if you have control over which of the two images to
> delete, you may also want to have control over the final filename used
> for the merged image (that is, in the 5% dirty case, use the
> snapshot->base merge followed by rename(base,snapshot), rather than
> wasting time on the base->snapshot merge, to still get the end result
> that the final filename is snapshot).

I agree with your analysis. The current behaviour is blocking us from
using qcow2 snapshots while your RFC fix the issues.

But in your last sentence, what do you mean by "to still get the end
result that the final filename is snapshot"? As end result, are you
talking about:

1) the filename (which would mean we could have moving path for disks)

or

2) the content (the snapshot content is in the final file, always in the
   path of the base file)

?

-- 
Nicolas Sebrecht