If I'm understanding the request right, we need a new virDomainBlockCopy API that exposes the full power of qemu's drive-mirror (the existing virDomainBlockRebase with the VIR_DOMAIN_BLOCK_REBASE_COPY flag was a limited-use-case hack for one specific case of drive-mirror).  Will persistent bitmaps be completed in time to design the API with that in mind?

This is for programs who wants to snoop the I/O of a VM, for example anti-viruses.  The program provides an NBD server on a TCP or Unix socket and the VM sends I/O there via the normal drive-mirror job.

I don't know if a new API is needed.  A URI can represent the location of the NBD server.  I think for simplicity a new kind of block job should be added, because block-job-complete does not really make sense in this case.

Persistent bitmaps are not needed for this application, it is just for online operations.

qemu is still debating the best approach; possibly through options of the new block-backup series.  I'm fairly certain that the best way to expose this in libvirt is via a new API, although it might be possible to cram it in via new flags to existing API if rebase considerations get in the way.

*** Bug 956577 has been marked as a duplicate of this bug. ***

Eric, this is not fleecing.  It wouldn't be for a point-in-time backup, it would be for drive-mirror.  I think bug 956577 has to be reopened.

*** Bug 956577 has been marked as a duplicate of this bug. ***

I'm still thinking that whether libvirt uses drive-mirror or drive-backup under the hood, that both mirroring to a remote NBD server and point-in-time fleecing are sufficiently related as to be covered by a single libvirt API virDomainBlockCopy.  Our existing use of drive-mirror is a very limited use case shoe-horned on top of virDomainBlockRebase, but that API is inadequate to express the full power of drive-mirror; and once you add enough knobs for the full power, it is just one more knob to state whether the copying is done as a point in time or as a continuous job.  At any rate, I hope to post an API to the libvirt list soon proposing how everything relates, and will make sure that both points are covered.

For now, I'm fine if 956577 remains closed dup, but we can reopen it if it makes it easier for QE to test both functions even if the testing uses a single API.  Just because qemu needs two separate BZ to expose two different QMP commands doesn't mean libvirt needs two BZ for exposing a fundamental feature (copying disk contents) with knobs (point-in-time vs. continuous).

I am not sure how this would indeed be implemented as the same API.  For this case, the NBD server is provided by the client.  For fleecing, the NBD server is provided by QEMU.

It is indeed possible to use the QEMU NBD server without point-in-time snapshot, but this is not what this bug is about.  This bug is about having an external program that snoops guest I/O as it happens, and QEMU sending this I/O actively to the external program.

RHEL 7.2 picks up virDomainBlockCopy() (since libvirt 1.2.8 upstream) via rebase, which allows targetting nbd or any other network destination of drive-mirror.

(In reply to Eric Blake from comment #14)
> RHEL 7.2 picks up virDomainBlockCopy() (since libvirt 1.2.8 upstream) via
> rebase, which allows targetting nbd or any other network destination of
> drive-mirror.

I did a blockcopy and specified a gluster based file as destination, but failed due to non-file destination not supported yet. Could you please hint me how to verify it. 

Thanks 
Yang

libvirt-1.2.17-10.el7.x86_64
qemu-kvm-rhev-2.3.0-25.el7.x86_64

#  virsh blockcopy virt-tests-vm1 vda --xml copy.xml --wait --verbose 
error: argument unsupported: non-file destination not supported yet

# cat copy.xml 
<disk type='network' device='disk'>
      <driver name='qemu' type='raw'/>
      <source protocol='gluster' name='gluster-vol1/copy'>
        <host name='10.66.4.164' port='24007'/>
      </source>
      <target dev='vda' bus='virtio'/>
    </disk>

Ouch - we still haven't wired it up in libvirt :(  From qemu/qemu_domain.c:

/* bandwidth in bytes/s.  Caller must lock vm beforehand, and not
 * access mirror afterwards.  */
static int
qemuDomainBlockCopyCommon(virDomainObjPtr vm,
...
    /* Prepare the destination file.  */
    /* XXX Allow non-file mirror destinations */
    if (!virStorageSourceIsLocalStorage(mirror)) {
        virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s",
                       _("non-file destination not supported yet"));
        goto endjob;
    }

I'll have to defer this; I think that in order for this feature to work, we need qemu's blockdev-add to work for all destinations, and libvirt to drive that.

> we need qemu's blockdev-add to work for all destinations, and libvirt
> to drive that.

Why?  drive-mirror supports gluster and NBD URIs for example.

(In reply to Paolo Bonzini from comment #21)
> > we need qemu's blockdev-add to work for all destinations, and libvirt
> > to drive that.
> 
> Why?  drive-mirror supports gluster and NBD URIs for example.

drive-mirror supports a single 'target' destination, which is only good for local files or URI-encoded names.  Better is the 'node-name' destination which supports _any_ BDS destination - except that you create BDS destinations by 'blockdev-add'.  And 'blockdev-add' isn't complete yet (closer in qemu 2.8, and shooting for qemu 2.9 - but the libvirt still has to use it)