Yuck... Well because we already have allowed this error to propagate, we won't be able to check and fail during the parsing phase, since that would result in a running domain with this bad configuration disappearing when libvirtd was restarted.

So the fix will have to be to inhibit guest startup when the condition is found, but only for new starts and not via the hotplug path since that path already has checks to ensure the provided target name doesn't already exist.

That is assuming the above configuration, if one tried to:
    qemu-img create -f raw /var/lib/libvirt/images/r7b.img 1G
    virsh attach-disk r7a /var/lib/libvirt/images/r7b.img sda

then libvirt would fail with:

   error: Failed to attach disk
   error: operation failed: target sda already exists

However, due to how the code works - on the guest the "second" sda listed in the XML above would end up being recognized as "sdb" (guest startup ignores the target name).  Unfortunately, this leads to the following gem in the same configuration but trying 'sdb' instead:

    virsh attach-disk r7a /var/lib/libvirt/images/r7b.img sdb
    error: Failed to attach disk
    error: internal error: unable to execute QEMU command 'device_add': Duplicate ID 'scsi0-0-1' for device

I'm working on a patch to be submitted upstream shortly.

Patches posted upstream:

http://www.redhat.com/archives/libvir-list/2015-February/msg01192.html

Patches pushed upstream:

commit id:
e0e290552bbbbd449399c9144b6b5b442b973de7

$ git describe e0e290552bbbbd449399c9144b6b5b442b973de7
v1.2.13-27-ge0e2905
$

I can reproduce it 
Verify version :
libvirt-1.2.16-1.el7.x86_64
qemu-kvm-rhev-2.3.0-2.el7.x86_64

Verify the firsh patch :
1.domblklist to understand disk volume syntax , the volume source can be listed 
1.1 add a volume disk to guest , using domblklist to check 
#virsh dumpxml r72 | grep disk -A 9
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/r7.2.qcow2'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='qcow2'/>
      <source startupPolicy='optional'/>
      <backingStore/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='volume' device='disk'>
      <driver name='qemu' type='raw'/>
      <source pool='iscsi-pool2' volume='unit:0:0:1' mode='host'/>
      <backingStore/>
      <target dev='sdb' bus='scsi'/>
      <alias name='scsi0-0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='network' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source protocol='gluster' name='gluster-vol1/qcow2.img'>
        <host name='$IP'/>
      </source>
      <backingStore/>
      <target dev='sdc' bus='scsi'/>
      <alias name='scsi0-0-0-2'/>
      <address type='drive' controller='0' bus='0' target='0' unit='2'/>
    </disk>

# virsh domblklist r72 --details
Type       Device     Target     Source
------------------------------------------------
file       disk       vda        /var/lib/libvirt/images/r7.2.qcow2
block      cdrom      hda        -
volume     disk       sdb        unit:0:0:1
network    disk       sdc        gluster-vol1/qcow2.img

The volume source can be displayed as expected . 

2.Disallow duplicated target 'dev' values
2.1 start a guest with two disk has same target dev 
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/qcow2.img'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/qcow2-2.img'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

#virsh start r72 
error: Failed to start domain r72
error: XML error: target 'sda' duplicated for disk sources '/var/lib/libvirt/images/qcow2-2.img' and '/var/lib/libvirt/images/qcow2.img'

2.2 attach disk using same target dev which has been used in guest 
# virsh domblklist r72
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/r7.2.qcow2
sda        /var/lib/libvirt/images/qcow2.img
sdb        unit:0:0:1

# virsh attach-disk r72 /var/lib/libvirt/images/qcow2-2.img sdb --subdriver qcow2 
error: Failed to attach disk
error: operation failed: target sdb already exists

# virsh attach-disk r72 /var/lib/libvirt/images/qcow2-2.img sdb --subdriver qcow2 --config
error: Failed to attach disk
error: Requested operation is not valid: target sdb already exists

2.3 change sdb to sdc , attch successfully .
# virsh attach-disk r72 /var/lib/libvirt/images/raw.img sdc 
Disk attached successfully

# virsh domblklist r72
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/r7.2.qcow2
sda        /var/lib/libvirt/images/qcow2.img
sdb        unit:0:0:1
sdc        /var/lib/libvirt/images/raw.img

As above , volume source can be displayed using domblklist ; 
and libvirt disallow duplicated target 'dev' values when multi disks attached to the same controller .It will give clear error message .

Hi John , 
I also tested using same 'target dev' with different bus .It can be define and start successfully . 
It gives confused display through 'domblklist' and I think it has impact on virsh command like detach-disk / blockcommit and so on .
Details like following , I cannot detach usb sdb disk if I am not detach scsi sdb disk first , or I cannot just blockcommit ide sdb disk because it will find scsi sdb disk first . 

    <disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/qcow2-2.img'/>
      <backingStore/>
      <target dev='sdb' bus='scsi'/>    <==scsi disk 
      <alias name='scsi0-0-0-2'/>
      <address type='drive' controller='0' bus='0' target='0' unit='2'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/qcow2.img'/>
      <backingStore/>
      <target dev='sdb' bus='usb'/>   <=== usb disk 
      <alias name='usb-disk1'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/raw.img'/>
      <backingStore/>
      <target dev='sdb' bus='ide'/>   <=== usb disk 
      <alias name='ide0-0-1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

# virsh domblklist r72 --details
Type       Device     Target     Source
------------------------------------------------
file       disk       vda        /var/lib/libvirt/images/r7.2.qcow2
volume     disk       sda        unit:0:0:1
file       disk       sdb        /var/lib/libvirt/images/qcow2-2.img (scsi disk)
file       disk       sdb        /var/lib/libvirt/images/qcow2.img (usb disk)
file       disk       sdb        /var/lib/libvirt/images/raw.img (ide disk)

Should these need further modification ? 
Thanks.

This is a slightly different problem - cross bus validation that the target names are unique as opposed to only validating that the target name is not duplicated for the same bus...  I guess that wasn't considered when first processing this.

Luckily the fix is simple - the current check from the patch is:

+            if (def->disks[i]->bus == def->disks[j]->bus &&
+                STREQ(def->disks[i]->dst, def->disks[j]->dst)) {

Looks like removing the bus check will solve this issue...

I'll move this one back to assigned (me).

I've posted a patch upstream already to resolve along with a DO_TEST_FAILURE entry, see:

http://www.redhat.com/archives/libvir-list/2015-June/msg00974.html

FWIW: If the test from my patch didn't expect a failure, the error would be:

Domain Config error : XML error: target 'sda' duplicated for disk sources '/tmp/usbdisk.img' and '/tmp/idedisk.img'

Patch has been pushed upstream:

commit 2e09729b1c1cc0096be4edd2d939bf1044aec506
Author: John Ferlan <jferlan>
Date:   Thu Jun 18 16:00:53 2015 -0400

    conf: Don't allow duplicated target names regardless of bus
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1142631
    
    Commit id 'e0e290552' added a check to determine if the same bus
    had the same target value.  It seems that's not quite good enough
    as the check should check the target name value regardless of bus type.
    
    Also added a DO_TEST_DIFFERENT to exhibit the issue

$ git describe 2e09729b1c1cc0096be4edd2d939bf1044aec506
v1.2.17-59-g2e09729
$

Verify version :
libvirt-1.2.17-2.el7.x86_64
qemu-kvm-rhev-2.3.0-9.el7.x86_64

Steps :

1. define a guest with two disks has same target dev and different bus type :
# virsh dumpxml r72 | grep disk -A 6
 
<disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/qcow2-2.img'/>
      <target dev='sdb' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/raw.img'/>
      <target dev='sdb' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>

2. try to start it , fail to start because duplicated target dev.

#virsh start r72 

error: Failed to start domain r72
error: XML error: target 'sdb' duplicated for disk sources '/var/lib/libvirt/images/raw.img' and '/var/lib/libvirt/images/qcow2-2.img'

3.other verify steps are same as comment7

According to comment7 and above steps , move this bug to verified .

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/RHBA-2015-2202.html