Moving to qemu-kvm-rhev, and a status update:

This is technically already possible upstream (and in rhev 2.6.0!) but it's not well tested and we need to do more work to create proper scope and testing for the workflow.

There are many potential dangerous uses of the feature given certain configurations, and more work needs to be done to eke out a well defined scope for this feature before we advertise its use.

Status remains the same; we need a proper testing framework and a formalized API to utilize the feature, but it remains technically possible.

Debate on proper API is occurring upstream right now (2.12 and beyond)

(In reply to Hugh Brock from comment #0)
> We need cheap point-in-time snapshots, as described below:
> 
> > This is not for backup, it is for inspection of a point-in-time
> > snapshot.  I used the word "backup" because it uses the same "tool"
> > (copy-on-write to the backup image), but it's for a wholly different
> > purpose.
> 
> Re-reading your email I think this is what you're describing:
> 
> 1. qemu-img create -f qcow2 -o backing_file=RUNNING-VM.img BACKUP.qcow2
>    (or perhaps a special way of creating this file within the running
>    QEMU so the running VM's image file uses a shared BlockDriverState.)
> 
> 2. start a point-in-time-backup job to BACKUP; it doesn't have to do a
>    full copy, just save the old contents whenever the guests does a
>    write.
> 
> 3. export BACKUP via the run-time NBD server.
> 
> Reads to sectors that have not be overwritten go to RUNNING-VM.img.
> 
> Reads to sectors that have been overwritten go to BACKUP.qcow2.
> 
> When fleecing completes, close and delete BACKUP.qcow2.
> 
> 
> This is nice.  VM write performance is slightly degraded during fleecing
> since we need to save sectors into BACKUP.qcow2 before overwriting them
> in RUNNING-VM.img.  Besides that there is no performance penalty and
> deletion is O(1).

Is this still desired? Meaning: is there customer demand for it in layered products? I haven't seen it prioritized by product management, but I believe we have all the pieces ready upstream to support this at this point.

We need to understand the details of the use-cases in order to provide the right APIs in libvirt though.

At present, fleecing is possible and is expected to be formalized as a supported API once libvirt uses it for incremental backup purposes.

However, as a standalone feature, libvirt does not present know how to utilize this feature and cannot expose it to clients.

Moving this back to "NEW" for now to indicate that nobody is working on the formalized API, though the backend primitives to enable it in QEMU are complete.

Closing this for lack of information.
Please re-open if there's a business case for it that can help shape the API.