So the problem is that qemu reports the filename of the LUKS layer differently from the file name of the backing file:

"file": "json:{\"driver\": \"luks\", \"file\": {\"driver\": \"file\", \"filename\": \"/tmp/luks\"}, \"key-secret\": \"ide0-0-1-luks-secret0\"}"

vs.

"file": "/tmp/luks"

This means that the best-effort node name detection code is not able to figure out the node-name of the backing file.

This will be fixed by libvirt switching to provide node-names manually when starting qemu, rather than adding a temporary hack to the detection code.

Upstream fixes this in the refactor of the node detection code:

commit 0175dc6ea024d4edd0f59571c3f5fa80d1ec1c0e
Author: Peter Krempa <pkrempa>
Date:   Wed Jul 26 09:36:21 2017 +0200

    qemu: block: Refactor node name detection code
    
    Remove the complex and unreliable code which inferred the node name
    hierarchy only from data returned by 'query-named-block-nodes'. It turns
    out that query-blockstats contain the full hierarchy of nodes as
    perceived by qemu so the inference code is not necessary.
    
    In query blockstats, the 'parent' object corresponds to the storage
    behind a storage volume and 'backing' corresponds to the lower level of
    backing chain. Since all have node names this data can be really easily
    used to detect node names.
    
    In addition to the code refactoring the one remaining test case needed
    to be fixed along.

Following test case shows that libvirt can detect the node name for the LUKS volume:

commit 86d8d11c148d6c99e53bbd92867c13d353530e5d
Author: Peter Krempa <pkrempa>
Date:   Thu Jul 27 10:26:41 2017 +0200

    tests: qemumonitorjson: Test extraction of LUKS node names
    
    Test file created by:
    
    qemu-img create -f luks /var/lib/libvirt/images/luks 10M \
            -o key-secret=asdf --object secret,id=asdf,format=raw,data=asdf
    
    Used in libvirt as:
     <disk type='file' device='disk'>
       <driver name='qemu' type='raw'/>
       <source file='/var/lib/libvirt/images/luks'/>
       <target dev='vda' bus='virtio'/>
       <encryption format='luks'>
         <secret type='passphrase' uuid='9b2c831a-fdb9-4c09-873c-1959580589e1'/>
       </encryption>
     </disk>

Verified on: 
libvirt-3.8.0-1.el7.x86_64

PASSED


## cat secret
      <secret ephemeral='no' private='yes'>
         <description>LUKS Sample Secret</description>
         <usage type='volume'>
            <volume>/var/lib/libvirt/images/luks.img</volume>
         </usage>
      </secret>

## virsh secret-define secret 
Secret 55e8fb24-e630-4dc7-9de0-a1c2e2f7456a created

## MYSECRET=`printf %s "redhat" | base64`

## virsh secret-set-value 55e8fb24-e630-4dc7-9de0-a1c2e2f7456a $MYSECRET
Secret value set

## qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" | base64`,format=base64 -o key-secret=sec0 /var/lib/libvirt/images/luks.img 1G

## qemu-img create -f luks --object secret,id=sec0,data=`printf %s "redhat" | base64`,format=base64 -o key-secret=sec0 /var/lib/libvirt/images/luks.img 1G
Formatting '/var/lib/libvirt/images/luks.img', fmt=luks size=1073741824 key-secret=sec0

## virsh dumpxml v | grep secret -a6
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/luks.img'/>
      <target dev='vdb' bus='virtio'/>
      <encryption format='luks'>
        <secret type='passphrase' uuid='55e8fb24-e630-4dc7-9de0-a1c2e2f7456a'/>
      </encryption>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </disk>
...

## virsh domblklist v
Target     Source
------------------------------------------------
...
vdb        /var/lib/libvirt/images/luks.img

## virsh domblkthreshold v vdb 100M; echo $?
0

## virsh domstats v --block | grep threshold
  block.1.threshold=104857600

## virsh event --event block-threshold --loop

use virt-manager or another termianl to login the VM, and in VM, run:
root@vm # dd if=/dev/urandom of=/dev/vda bs=1M count=101
101+0 records in
101+0 records out
105906176 bytes (106 MB) copied, 1.46398 s, 72.3 MB/s

back to test host, and event captrued as follow:
## virsh event --event block-threshold --loop
event 'block-threshold' for domain v: dev: vdb(/var/lib/libvirt/images/luks.img) 104857600 4096

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://access.redhat.com/errata/RHEA-2018:0704