RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1210587 - When libvirt automatically fill up SCSI virtual disk's target address, it doesn't check existing hostdev SCSI device's target address, and this will cause conflict.
Summary: When libvirt automatically fill up SCSI virtual disk's target address, it doe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-10 06:42 UTC by yisun
Modified: 2016-11-03 18:16 UTC (History)
7 users (show)

Fixed In Version: libvirt-1.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 18:16:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2577 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2016-11-03 12:07:06 UTC

Description yisun 2015-04-10 06:42:05 UTC
Description of problem:
When libvirt automatically fill up SCSI virtual disk's target address, it doesn't check existing hostdev SCSI device's target address, and this will cause conflict.

Version-Release number of selected component (if applicable):
libvirt-1.2.14-1.el7.x86_64  
qemu-kvm-rhev-2.2.0-8.el7.x86_64
kernel-3.10.0-234.el7.x86_64


How reproducible:
100%

Steps to Reproduce:
1. edit a vm's xml and leave one scsi virtual disk's target address blank. And save it. 
#virsh edit vm1
....
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel7.0.qcow2'/>
      <target dev='sda' bus='scsi'/>
</disk>
....
<hostdev mode='subsystem' type='scsi' managed='no'>
      <source protocol='iscsi' name='lento.com:iscsi_1/1'>
        <host name='10.xx.xx.xx' port='3260'/>
      </source>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
 </hostdev>

2. check the vm's xml and the disk's target address is automatically filled up but conflict with existing hostdev's target address.
#virsh dumpxml vm1
   <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel7.0.qcow2'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>   <=== here the address is automatically generated but duplicate with following hostdev target address.
    </disk>
...
    <hostdev mode='subsystem' type='scsi' managed='no'>
      <source protocol='iscsi' name='lento.com:iscsi_1/1'>
        <host name='10.66.100.103' port='3260'/>
      </source>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>  <==== existing address
    </hostdev>

3. Conflict happens.
#virsh start vm1
error: Failed to start domain vm1
error: internal error: process exited while connecting to monitor: 2015-04-09T09:52:39.421294Z qemu-kvm: -device scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-hostdev0,id=hostdev0: lun already used by 'scsi0-0-0-0'
2015-04-09T09:52:39.421414Z qemu-kvm: -device scsi-generic,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-hostdev0,id=hostdev0: Device 'scsi-generic' could not be initialized

Actual result:
Address conflict

Expected resutl:
Conflict should be avoided. 


Additional info:
This can also be reproduced in disk hot-plug, which is a more common usage. 

[root@localhost ~]# cat disk.xml
<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/test.qcow2'/>
      <target dev='sda' bus='scsi'/>
</disk>

[root@localhost ~]# virsh attach-device r71 disk.xml --config
Device attached successfully

[root@localhost ~]# virsh dumpxml r71| grep -E "/disk|/hostdev" -B8
  </pm>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/r71_gpt.1425107188'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/test.qcow2'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>    <======= conflict
--
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <hostdev mode='subsystem' type='scsi' managed='no'>
      <source protocol='iscsi' name='lento.com:iscsi_1/1'>
        <host name='10.66.100.103' port='3260'/>
      </source>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>    <===== conflict
    </hostdev>

Comment 1 John Ferlan 2015-06-19 21:05:46 UTC
Interesting bug...  There are those that could say - since you defined the address for hostdev, then you should have done so for disk too, but it seems we can "avoid" this during the definition processing rather easily.  The question (or issue) is that any existing guest defined this way would disappear. Of course the fact that it couldn't be started anyway due to the error should make that a non issue; however, we'll see what upstream says.

The second/hotplug issue is a bit more tricky/obscure as the hotplug a <disk> device without an <address> supplied algorithm uses the target dev value ("sda") in order to attempt to fabricate an <address>.  If you had supplied "sdb" as the target dev value, then unit=1 would have been chosen (sdc would choose unit=2) - see virDiskNameToIndex().  And there's no hostdev conflict checking done.

NB: The virDiskNameToIndex() is done for <disk> elements as well - so for the first half of the problem - if you had defined using "sdb", then there would be no conflict. The 'assumption' in the code is that for adding an <address> to a <disk> is that the virDomainDiskDefDstDuplicates() "flagged" any possible target dev value duplicates, so the algorithm would work, except when hostdev's "steal" the address expected for a disk.

Adding in knowledge of <hostdev> into that algorithm won't necessarily work since <disk>'s are processed before <hostdev>'s.  

One possible option would be to assign <disk>'s to one controller while <hostdev>'s would be on different controller. Perhaps not the best use of resources, but it keeps the disk <address> algorithm "clean".

Going to keep thinking about this, but wanted to write something down before I forgot

Comment 2 John Ferlan 2015-07-22 15:00:01 UTC
Upstream series:

http://www.redhat.com/archives/libvir-list/2015-July/msg00870.html

addresses issue. This is the second pass. The first pass is here:

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

Comment 7 Pei Zhang 2016-05-26 06:04:57 UTC
Verified version:
libvirt-1.3.4-1.el7.x86_64
qemu-kvm-rhev-2.6.0-3.el7.x86_64

Verified steps:
1)Auto generated address for scsi disk and hostdev.
Edit guest and add scsi disk and iscsi hostdev without address, after save the configuration, it will add address automatically.
#virsh edit r72 
# virsh dumpxml r72 | grep disk -A 9

    <disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/a.qcow2'/>
      <target dev='sda' bus='scsi'/>
    </disk>
......
    <hostdev mode='subsystem' type='scsi' managed='no'>
      <source protocol='iscsi' name='iqn.2015-07.com.example.5.184:t1/0'>
        <host name='$IP' port='3260'/>
      </source>
    </hostdev>

Save and check again, auto added address.
# virsh dumpxml r72 | grep disk -A 9
    <disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/a.qcow2'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

# virsh dumpxml r72 | grep hostdev -A 9
    <hostdev mode='subsystem' type='scsi' managed='no'>
      <source protocol='iscsi' name='iqn.2015-07.com.example.5.184:t1/0'>
        <host name='$IP' port='3260'/>
      </source>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </hostdev>
   

2) Check hostdev address conflicts with disk address.
 
2.1) Edit guest with scsi hostdev using address scsi 0-0-0-0, 
and configure a scsi disk with dev='sda' bug without address, it should fail to save.

#virsh edit r72 
<disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/a.qcow2'/>
      <target dev='sda' bus='scsi'/>
    </disk>

<hostdev mode='subsystem' type='scsi' managed='no'>
      <source protocol='iscsi' name='iqn.2015-07.com.example.5.184:t1/0'>
        <host name='$IP' port='3260'/>
      </source>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </hostdev>
 
# virsh edit r72
error: unsupported configuration: using disk target name 'sda' conflicts with SCSI host device address controller='0' bus='0' target='0' unit='0
Failed. Try again? [y,n,i,f,?]:

change scsi disk dev='sda' to 'sdb', it will save successfully.

2.2) start a guest with scsi hostdev has address scsi 0-0-0-0, then attach a scsi disk with dev=sda.
#virsh dumpxml rhel72|grep hostdev -A 9  
  <hostdev mode='subsystem' type='scsi' managed='no'>
      <source protocol='iscsi' name='iqn.2015-07.com.example.5.184:t1/0'>
        <host name='$IP' port='3260'/>
      </source>
      <alias name='hostdev0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </hostdev>
#cat scsi-disk.xml
<disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/a.qcow2'/>
      <target dev='sda' bus='scsi'/>
    </disk>

# virsh attach-device rhel72 scsi-disk.xml
error: Failed to attach device from a-disk.xml
error: unsupported configuration: using disk target name 'sda' conflicts with SCSI host device address controller='0' bus='0' target='0' unit='0

# virsh attach-device rhel72 scsi-disk.xml --config
error: Failed to attach device from a-disk.xml
error: unsupported configuration: using disk target name 'sda' conflicts with SCSI host device address controller='0' bus='0' target='0' unit='0

change scsi disk dev='sda' to 'sdb', it will attach successfully.

3) Try controller add if there is useful one when seaching for hostdev address.

3.1> start guest without scsi controller
# virsh dumpxml r72|grep iscsi

3.2> attach scsi hostdev
# virsh attach-device r72 hostdev-scsi-net.xml 
Device attached successfully

3.3> check guest was added new controller. 
# virsh dumpxml r72|grep scsi -A 9
    <controller type='scsi' index='0'>
      <alias name='scsi0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </controller>

# virsh dumpxml r72|grep iscsi -A 9
      <source protocol='iscsi' name='iqn.2015-07.com.example.5.184:t1/0'>
        <host name='$IP' port='3260'/>
      </source>
      <alias name='hostdev0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </hostdev>


4) Check for SCSI devices a 'drive' address type must be used.
4.1) attach scsi hostdev without address type
# cat hostdev-scsi-net.xml
<hostdev mode='subsystem' type='scsi' managed='no'>
	<source protocol='iscsi' name='iqn.2015-07.com.example.5.184:t1/0'>
<host name='$IP' port='3260'/>
</source>
<address controller='0' bus='0' target='0' unit='1'/>
</hostdev>

# virsh attach-device r72 hostdev-scsi-net.xml
error: Failed to attach device from hostdev-scsi-net.xml
error: internal error: No type specified for device address

4.2) check attach scsi hostdev with address type is not 'drive'
# cat hostdev-scsi-net.xml
<hostdev mode='subsystem' type='scsi' managed='no'>
	<source protocol='iscsi' name='iqn.2015-07.com.example.5.184:t1/0'>
<host name='$IP' port='3260'/>
</source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</hostdev>

# virsh attach-device r72 hostdev-scsi-net.xml
error: Failed to attach device from hostdev-scsi-net.xml
error: XML error: SCSI host device must use 'drive' address type

As above, move this bug to verified.

Comment 9 errata-xmlrpc 2016-11-03 18:16:09 UTC
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


Note You need to log in before you can comment on or make changes to this bug.