Well, after some debug, seem this is a qemu issue. 
When guest is in mirror phase, 

# rpm -q qemu-kvm-rhev libvirt
qemu-kvm-rhev-2.2.0-5.el7.x86_64
libvirt-1.2.8-16.el7_1.1.x86_64

# virsh qemu-monitor-command test '{"execute":"query-block-jobs"}' 
{"return":[{"io-status":"ok","device":"drive-virtio-disk0","busy":false,"len":0,"offset":0,"paused":false,"speed":0,"ready":true,"type":"mirror"}],"id":"libvirt-10"}

Both len and offset is 0, which means both info.end and info.cur is 0. 
so vshPrintJobProgress will print nothing out.

..
        vshPrintJobProgress(vshDomainBlockJobToString(info.type),
                            info.end - info.cur, info.end);
..
static void
vshPrintJobProgress(const char *label, unsigned long long remaining,
                    unsigned long long total)
{
    int progress;

    if (total == 0)
        /* migration has not been started */
        return;
..

Try with qemu directly


{"execute":"drive-mirror","arguments":{"device":"drive-virtio-disk0","mode":"absolute-paths","format":"qcow2","target":"/var/lib/libvirt/images/test.copy","sync":"full"}}
{"return": {}}
{"timestamp": {"seconds": 1425882693, "microseconds": 587594}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-virtio-disk0", "len": 0, "offset": 0, "speed": 0, "type": "mirror"}}


{"execute":"query-block-jobs"}
{"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": false, "len": 0, "offset": 0, "paused": false, "speed": 0, "ready": true, "type": "mirror"}]}

(qemu) info block
drive-virtio-disk0: /var/lib/libvirt/images/vm3.img (qcow2)

{"execute": "block-job-complete", "arguments": { "device": "drive-virtio-disk0"}}
{"return": {}}
{"timestamp": {"seconds": 1425883294, "microseconds": 349647}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-virtio-disk0", "len": 0, "offset": 0, "speed": 0, "type": "mirror"}}


{"execute":"query-block-jobs"}
{"return": []}

(qemu) info block
drive-virtio-disk0: /var/lib/libvirt/images/test.copy (qcow2)

Test with qemu-kvm-rhev-2.2.0-5.el7.x86_64 on my local host, did not hit the problem, the most common mirror works correctly:

{ "execute": "drive-mirror", "arguments": { "device": "drive-virtio-disk0", "target": "/root/sn1", "format": "qcow2", "mode": "absolute-paths", "sync": "full" } }
{"return": {}}


{ "execute" : "query-block-jobs", "arguments" : {} }
{"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": true, "len": 5136515072, "offset": 147718144, "paused": false, "speed": 0, "ready": false, "type": "mirror"}]}

{ "execute" : "query-block-jobs", "arguments" : {} }
{"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": true, "len": 5136711680, "offset": 695599104, "paused": false, "speed": 0, "ready": false, "type": "mirror"}]}

after steady state, block_job_complete, guest works correctly.

Please notice, I use empty qcow2 format file for guest

I think I've dabbled with patching this upstream (although the conversation has died down with me still not committing anything yet...):

https://www.redhat.com/archives/libvir-list/2015-February/msg00053.html

Re-assigning to Eric since he already posted a patch for this.

I'll have to see if the situation is still present after Peter's work at:
 commit faa143912381aa48e33839b194b32cc14d574589
Author: Peter Krempa <pkrempa@redhat.com>
Date:   Mon Jul 13 17:04:49 2015 +0200

    virsh: Refactor block job waiting in cmdBlockCopy
    
    Similarly to the refactor of cmdBlockCommit in a previous commit this
    does the same change for cmdBlockCopy.

If so, I'll try and revive my earlier patch.

(In reply to Eric Blake from comment #7)
> I'll have to see if the situation is still present after Peter's work at:
>  commit faa143912381aa48e33839b194b32cc14d574589
> Author: Peter Krempa <pkrempa@redhat.com>
> Date:   Mon Jul 13 17:04:49 2015 +0200
> 
>     virsh: Refactor block job waiting in cmdBlockCopy
>     
>     Similarly to the refactor of cmdBlockCommit in a previous commit this
>     does the same change for cmdBlockCopy.
> 
> If so, I'll try and revive my earlier patch.

Eric,

This still happen with v1.2.18-33-g6da3b69. So need your earlier patch.

It's still not fixed since the bug is only in the percentage display function in virsh which wasn't touched. The function expects some progress to display the state so we will need to work it around.

commit 7acfb940f712980415e82a46a7de7adb11163a10
Author: Peter Krempa <pkrempa@redhat.com>
Date:   Fri Sep 11 21:34:24 2015 +0200

    virsh: Fix job status indicator for 0 length block jobs
    
    Although 0 length block jobs aren't entirely useful, the output of virsh
    blockjob is empty due to the condition that suppresses the output for
    migration jobs that did not start. Since the only place that actually
    uses the condition that suppresses the output is in migration, let's
    move the check there and thus add support for 0 of 0 equaling to 100%.

Verified on libvirt-1.3.1-1.el7.x86_64

Steps
1. Prepare a transient guest
# virsh create r7.xml 
Domain r7 created from r7.xml

2. Do blockcopy job
# virsh blockcopy r7 vda /var/lib/libvirt/images/r7.clone --verbose --wait 

Now in mirroring phase

Note: vda is an empty disk

3. Check job status by blockjob
# virsh blockjob r7 vda 
Block Copy: [100 %]

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2577.html