Fixed upstream:

commit 93575f345116fe1413f6fe3109227b8be2f416da
Author: Peter Krempa <pkrempa>
Date:   Mon Sep 25 11:44:00 2017 +0200

    qemu: block: Use correct alias when extracting disk node names
    
    The alias recorded in disk->info.alias is the alias for the frontend
    device but we are interested in the backend drive. This messed up the
    disk node name extraction code as qemu reports the drive alias in the
    block query commands. This was broken in the node name detector
    refactoring done in commit 0175dc6ea024d

Test env components:
kernel-3.10.0-734.el7.x86_64
libvirt-3.8.0-1.el7.x86_64
qemu-kvm-rhev-2.10.0-2.el7.x86_64

Steps to verify:
@Terminal 1:
1. Start a vm whose its second disk's xml as follow:
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/test.raw'/>
      <backingStore/>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </disk>

# virsh start lmn
Domain lmn started

2. Set the domain block threshold of its vdb:
# virsh domblkthreshold lmn vdb 200M

## virsh domstats lmn --block | grep threshold
  block.1.threshold=209715200

3. Check the block threshold event: 
# virsh event --event block-threshold --loop

@Terminal 2:
1. Connect to domain:
# virsh console lmn
Connected to domain lmn
Escape character is ^]
Red Hat Enterprise Linux Server 7.4 (Maipo)
Kernel 3.10.0-693.el7.x86_64 on an x86_64
localhost login: root
Password: 
Last login: Thu Oct 19 14:01:24 on ttyS0

2. [In guest]
# mkfs.ext4 /dev/vdb
# mount /dev/vdb /mnt
# dd if=/dev/urandom of=/mnt/a bs=1M count=300
300+0 records in
300+0 records out
314572800 bytes (315 MB) copied, 2.82178 s, 111 MB/s
# sync

@Terminal 1:
virsh event --event block-threshold --loop
event 'block-threshold' for domain lmn: dev: vdb(/var/lib/libvirt/images/test.raw) 209715200 192946176   <=== event captured

It also be verified on qcow2 type(driver),block type(disk) and volume type(disk).
The results are as expected, move this bug to be verified.

Hi Peter,
For domblkthreshold in `man virsh`, it describe "dev specifies the disk device target or backing chain element of given device using the 'target[1]' syntax." So I use backing chain element to test it, and found the below questions:
(1)It can be set by `virsh domblkthreshold rhel7 vda[0] 2G`, but actually we don't have vda[0] in chain.
(2)It can't use vda[1],vda[2]..to set the block threshold.
So, is it only a doc error or a libvirt bug? Thanks.

Test steps:
1. Prepare a running guest.
2. Do snapshot for it, and check dumpxml.
# virsh dumpxml rhel7 | grep disk -a8
 <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel7.p2'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/var/lib/libvirt/images/rhel7.p1'/>
        <backingStore type='file' index='2'>
          <format type='qcow2'/>
          <source file='/var/lib/libvirt/images/rhel7.qcow2'/>
          <backingStore/>
        </backingStore>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/>
    </disk>
3. Set block threshold for vda device.
# virsh domblkthreshold rhel7 vda[1] 2G
# virsh domstats rhel7 --block | grep threshold
no output

# virsh domblkthreshold rhe7 vda[2] 2G
# virsh domstats rhel7 --block | grep threshold
no output

# virsh domblkthreshold rhel7 vda[0] 2G
# virsh domstats rhel7 --block | grep threshold
  block.0.threshold=2147483648

the test version for comment 6:
libvirt-3.9.0-9.el7.x86_64
qemu-kvm-rhev-2.10.0-18.el7.x86_64

vda[0] is not currently a valid index, since there is no <backingStore index='0'> You can use only the valid ones.

vda[1],vda[2] is not possible. The API operates only on a single target. You need to make two calls for both elements.

I think the docs are clear on the fact that the index must be found in the XMl and that only one target is legal.

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