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 1146837 - Libvirtd crash when defining scsi pool with 'scsi_host' type adapter and parentaddr attribute
Summary: Libvirtd crash when defining scsi pool with 'scsi_host' type adapter and pare...
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
medium
medium
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-26 08:18 UTC by Yang Yang
Modified: 2015-03-05 07:45 UTC (History)
6 users (show)

Fixed In Version: libvirt-1.2.8-6.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 07:45:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
back trace (6.60 KB, text/plain)
2014-09-26 08:18 UTC, Yang Yang
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0323 0 normal SHIPPED_LIVE Low: libvirt security, bug fix, and enhancement update 2015-03-05 12:10:54 UTC

Description Yang Yang 2014-09-26 08:18:14 UTC
Created attachment 941428 [details]
back trace

Description of problem:
Libvirtd crash when there is an existing SCSI pool defined with adapter type as
'scsi_host' and defining a new SCSI pool with adapter type as
'scsi_host' and parentaddr attribute defined


Version-Release number of selected component (if applicable):
libvirt-1.2.8-3.el7.x86_64


How producible:
100%

steps
1. create a vHBA
# cat vHBA.xml

    <device>
    <parent>scsi_host5</parent>
    <capability type='scsi_host'>
    <capability type='fc_host'>
    <wwnn>2101001b32a90002</wwnn>
    <wwpn>2101001b32a90003</wwpn>
    <capability type='vport_ops'/>
    </capability>
    </capability>
    </device>

# virsh nodedev-create vHBA.xml
Node device scsi_host13 created from vHBA.xml

# virsh nodedev-list scsi_host
scsi_host0
scsi_host1
scsi_host13    ----vHBA
scsi_host2
scsi_host3
scsi_host4
scsi_host5

# virsh nodedev-list --tree
........
+- pci_0000_04_00_1
  |       |
  |       +- scsi_host5
  |           |
  |           +- scsi_host13
  |           |   |     
  |           |   +- scsi_target13_0_2
  |           |   |   |
  |           |   |   +- scsi_13_0_2_0
  |           |   |       |
  |           |   |       +- block_sdd_3600a0b80005ad1d700002dde4fa32ca8
  |           |   |         
  |           |   +- scsi_target13_0_3
  |           |       |
  |           |       +- scsi_13_0_3_0
  |           |           |
  |           |           +- block_sde_3600a0b80005ad1d700002dde4fa32ca8


2. define/start a scsi pool with the following xml
# cat scsi-pool.xml
<pool type='scsi'>
<name>scsi-pool</name>
<source>
<adapter type='scsi_host' name='scsi_host13'/>
</source>
<target>
<path>/dev/disk/by-path</path>
<permissions>
<mode>0700</mode>
<owner>0</owner>
<group>0</group>
</permissions>
</target>
</pool>

[root@dell-pet105-04 yy]# virsh pool-define scsi-pool.xml
Pool scsi-pool defined from scsi-pool.xml

[root@dell-pet105-04 yy]# virsh pool-start scsi-pool
Pool scsi-pool started

3. define another scsi pool with the following xml
# cat scsi-pool-1.xml
<pool type='scsi'>
<name>scsi-pool-1</name>
<source>
<adapter type='scsi_host'>
<parentaddr unique_id='13'>
<address domain='0' bus='0x04' slot='0' function='1'/>
</parentaddr>
</adapter>
</source>
<target>
<path>/dev/disk/by-path</path>
<permissions>
<mode>0700</mode>
<owner>0</owner>
<group>0</group>
</permissions>
</target>
</pool>

# ps -ef|grep libvirtd
root     13833     1  0 22:07 ?        00:00:00 /usr/sbin/libvirtd


[root@dell-pet105-04 yy]# virsh pool-define scsi-pool-1.xml
error: Failed to define pool from scsi-pool-1.xml
error: End of file while reading data: Input/output error
error: Failed to reconnect to the hypervisor

# ps -ef|grep libvirtd
root     13970     1 15 22:09 ?        00:00:00 /usr/sbin/libvirtd


Actual results:
in step3: when defining 2nd scsi pool, libvirtd is restarted.

Expected results:
in step3: libvirtd should not be restarted

Additional info:
The issue can not be reproduced when Reversing above steps 2 & 3

If the scsi pool with 'scsi_host' type adapter
and parrentaddr attribute was defined first, then
defined the 2nd scsi pool with scsi_host type adpater
and name attribute defined. It PASSED.

Comment 2 John Ferlan 2014-09-30 15:46:56 UTC
Yuck - code didn't take into account having pool using one way to define things and incoming definition another way.

For the case that doesn't core - the success is probably not a good thing as you'll now have two pools defined to the same source, which isn't supposed to be allowed. In that case the incoming pool definition doesn't have a parentaddr or uniqueid filled in (they're zero), but due to how the structure is defined the matching will be able to proceed without failure with the comparison almost assuredly always being false, thus allowing two pools using the same source.

I'm putting together a patch to handle this - good catch...

I also noted another anomoly regarding matching with regard to using "host#" or "scsi_host#" for the name.  The former is the legacy scheme, but the matching of whether incoming definition is done only on the name.  So if you have a pool defined with "host4" and the incoming attempting to define a pool uses "scsi_host4" (which are technically the same thing), the comparison will fail thus allowing the "scsi_host4" source which is has the same source as "host4".

I'll be fixing that too!

Comment 5 Xuesong Zhang 2014-12-23 07:51:39 UTC
Verify this bug with the following package version:
libvirt-1.2.8-11.el7.x86_64
qemu-kvm-rhev-2.1.2-17.el7.x86_64
kernel-3.10.0-219.el7.x86_64

Steps:
1. prepare 2 type scsi pool, the source are point to same vHBA port.
# cat scsi-pool.xml 
<pool type='scsi'>
<name>scsi-pool</name>
<source>
<adapter type='scsi_host' name='scsi_host6'/>
</source>
<target>
<path>/dev/disk/by-path</path>
<permissions>
<mode>0700</mode>
<owner>0</owner>
<group>0</group>
</permissions>
</target>
</pool>

# cat scsi-pool-1.xml 
<pool type='scsi'>
<name>scsi-pool-1</name>
<source>
<adapter type='scsi_host'>
<parentaddr unique_id='6'>
<address domain='0' bus='0x04' slot='0' function='1'/>
</parentaddr>
</adapter>
</source>
<target>
<path>/dev/disk/by-path</path>
<permissions>
<mode>0700</mode>
<owner>0</owner>
<group>0</group>
</permissions>
</target>
</pool>

2. define and start one pool firt.
# virsh pool-define scsi-pool.xml 
Pool scsi-pool defined from scsi-pool.xml

# virsh pool-start scsi-pool
Pool scsi-pool started

# virsh pool-list --all
 Name                 State      Autostart 
------------------------------------------- 
 scsi-pool            active     no        

# virsh vol-list scsi-pool
 Name                 Path                                    
------------------------------------------------------------------------------
 unit:0:2:0           /dev/disk/by-path/pci-0000:04:00.1-fc-0x203600a0b85b5dd4-lun-0


3. make sure the libvirtd service is working well.
# ps -ef|grep libvirtd
root      1302     1  0 Dec22 ?        00:00:16 /usr/sbin/libvirtd

4. define another pool with same source, will report error as expected, libvirtd is stable, the pid of libvirtd is not changed.
# virsh pool-define scsi-pool-1.xml 
error: Failed to define pool from scsi-pool-1.xml
error: operation failed: Storage source conflict with pool: 'scsi-pool'

# ps -ef|grep libvirtd
root      1302     1  0 Dec22 ?        00:00:16 /usr/sbin/libvirtd

5. destroy and undefine this pool
# virsh pool-destroy scsi-pool
Pool scsi-pool destroyed

# virsh pool-undefine scsi-pool
Pool scsi-pool has been undefined

6. define and start 2nd pool first,
# virsh pool-define scsi-pool-1.xml 
Pool scsi-pool-1 defined from scsi-pool-1.xml

# virsh pool-start scsi-pool-1
Pool scsi-pool-1 started

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------      
 scsi-pool-1          active     no        

7. define another 1st pool failed as expected.
# virsh pool-define scsi-pool.xml 
error: Failed to define pool from scsi-pool.xml
error: operation failed: Storage source conflict with pool: 'scsi-pool-1'

Change the bug status to Verify.

Comment 7 errata-xmlrpc 2015-03-05 07:45:19 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-2015-0323.html


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