Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1458708

Summary: Cannot destroy a fc scsi pool if set its parent device to a non-HBA device
Product: Red Hat Enterprise Linux 7 Reporter: yisun
Component: libvirtAssignee: John Ferlan <jferlan>
Status: CLOSED ERRATA QA Contact: jiyan <jiyan>
Severity: low Docs Contact:
Priority: low    
Version: 7.4CC: hhan, jiyan, lmen, rbalakri, xuzhang
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-3.7.0-1.el7 Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 10:46:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description yisun 2017-06-05 09:40:36 UTC
Description of problem:
Cannot destroy a fc scsi pool if set it's parent device to a non-HBA device

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

How reproducible:
100%

Steps to Reproduce:
# virsh pool-dumpxml bugtest
<pool type='scsi'>
  <name>bugtest</name>
  <uuid>b10a124b-e2d8-4f0e-ad2a-c029e69566ad</uuid>
  <capacity unit='bytes'>85899345920</capacity>
  <allocation unit='bytes'>85899345920</allocation>
  <available unit='bytes'>0</available>
  <source>
    <adapter type='fc_host' parent='scsi_host1' managed='yes' wwnn='20000000c99e2b81' wwpn='10000000c99e2b81'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
    </permissions>
  </target>
</pool>
*** scsi_host1 is a sata disk ***
*** wwpn/wwnn is from scsi_host7 which is a hba card ***

## virsh pool-destroy bugtest
error: Failed to destroy pool bugtest
error: Requested operation is not valid: vport operation 'vport_delete' is not supported for host1
*** now it's still failed since libvirt tried to send a vport_delete to a non-fc host.

Actual results:
Failed to destroy the pool

Expected results:
Pool can be destroyed

Additional info:
This is from bz 1420740

Comment 2 John Ferlan 2017-07-05 11:04:41 UTC
Posted a couple of patches:

https://www.redhat.com/archives/libvir-list/2017-July/msg00029.html

patch 2/2 is the solution... 1/2 was determined while working through various options.  The key difference with this particular setup is usage of an HBA as the parent as opposed to usage of a vHBA as the parent which is the way the code was designed originally.  The whole purpose of providing an existing vHBA is to have the scsi_host that's being used be "unmanaged" by libvirt - that is someone creates the vHBA using nodedev, then creates a pool to use that nodedev/scsi_host, and of course doesn't expect libvirt to remove that nodedev/scsi_host when the pool is destroyed.   Using an HBA is/was in this manner quite unexpected. The HBA pool was expected to have the following:

<name>hba3_pool</name>
  <source>
    <adapter type='scsi_host' name='scsi_host3'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
  </target>
</pool>


and not need or use the 

<source>
  <adapter type='fc_host' [parent='scsi_hostN'] wwnn='HBA_wwn' wwpn='HBA_wwpn'/>
</source>

Comment 3 John Ferlan 2017-07-24 17:49:13 UTC
After a review or two, the following patch:

https://www.redhat.com/archives/libvir-list/2017-July/msg00840.html

from the series:

https://www.redhat.com/archives/libvir-list/2017-July/msg00837.html

has been pushed upstream:

$ git describe f7237d63e8f02f3689f9b63b413fae7d4221faa9
v3.5.0-240-gf7237d6
$ git show f7237d63e8f02f3689f9b63b413fae7d4221faa9
commit f7237d63e8f02f3689f9b63b413fae7d4221faa9
Author: John Ferlan <jferlan>
Date:   Thu Jul 20 11:14:46 2017 -0400

    storage: Check if provided parent is vHBA capable
    
    ...
    
    If the parent provided for the storage pool adapter is not vHBA
    capable, then issue a configuration error even though the provided
    wwnn/wwpn were found.
    
    It is a configuration error to provide a mismatched parent to
    the wwnn/wwpn. The @parent is optional and is used as a means to
    perform duplicate pool source checks.

Comment 5 jiyan 2017-09-21 03:53:26 UTC
Test env components:
libvirt-3.7.0-2.el7.x86_64
kernel-3.10.0-709.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.8.x86_64

Test env: The nodedev info in physical host is as follows: 
# virsh nodedev-list fc_host
scsi_host1
scsi_host8

# virsh nodedev-list scsi_host
scsi_host0
scsi_host1
scsi_host2
scsi_host3
scsi_host4
scsi_host5
scsi_host6
scsi_host7
scsi_host8

Test scenarios:
Scenario-1: Create 'scsi_host' type pool when the adapter is HBA device
1. Prepare the xml file used to define the pool
# cat pool.xml 
<pool type='scsi'>
  <name>pool</name>
  <source>
    <adapter type='scsi_host' name='scsi_host1'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
    </permissions>
  </target>
</pool>

2. Define and start the pool
# virsh pool-define pool.xml 
Pool pool defined from pool.xml

# virsh pool-build pool
Pool pool built

# virsh pool-start pool
Pool pool started

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       
 pool                 active     no        

3. Destroy and undefine the pool
# virsh pool-destroy pool
Pool pool destroyed

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       
 pool                 inactive   no        

# virsh pool-undefine pool
Pool pool has been undefined

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes     

Scenario-2: Create 'scsi_host' type pool when the adapter is non-HBA device
1. Prepare the xml file used to define the pool
# cat pool.xml 
<pool type='scsi'>
  <name>pool</name>
  <source>
    <adapter type='scsi_host' name='scsi_host2'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
    </permissions>
  </target>
</pool>

2. Define and start the pool
# virsh pool-define pool.xml 
Pool pool defined from pool.xml

# virsh pool-build pool
Pool pool built

# virsh pool-start pool
Pool pool started

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       
 pool                 active     no        

3. Destroy and undefine the pool
# virsh pool-destroy pool
Pool pool destroyed

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       
 pool                 inactive   no        

# virsh pool-undefine pool
Pool pool has been undefined

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes   

Scenario-3: Create 'scsi_host' type pool when the adapter is vHBA device
1. Create the vHBA
# cat vhba.xml 
<device>
  <parent>scsi_host8</parent>
  <capability type='scsi_host'>
   <capability type='fc_host'>
     <wwnn>1001001b32a9da5e</wwnn>
     <wwpn>1101001b32a9da5e</wwpn>
   </capability>
  </capability>
</device>

# virsh nodedev-create vhba.xml 
Node device scsi_host17 created from vhba.xml

# virsh nodedev-dumpxml scsi_host17
<device>
  <name>scsi_host17</name>
  <path>/sys/devices/pci0000:00/0000:00:03.0/0000:08:00.1/host8/vport-8:0-8/host17</path>
  <parent>scsi_host8</parent>
  <capability type='scsi_host'>
    <host>17</host>
    <unique_id>17</unique_id>
    <capability type='fc_host'>
      <wwnn>1001001b32a9da5e</wwnn>
      <wwpn>1101001b32a9da5e</wwpn>
      <fabric_wwn>ffffffffffffffff</fabric_wwn>
    </capability>
  </capability>
</device>

2. Prepare the xml file used to define the pool
# cat pool.xml 
<pool type='scsi'>
  <name>pool</name>
  <source>
    <adapter type='scsi_host' name='scsi_host17'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
    </permissions>
  </target>
</pool>

3. Define and start the pool
# virsh pool-define pool.xml 
Pool pool defined from pool.xml

# virsh pool-build pool
Pool pool built

# virsh pool-start pool
Pool pool started

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       
 pool                 active     no        

4. Destroy and undefine the pool
# virsh pool-destroy pool
Pool pool destroyed

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       
 pool                 inactive   no        

# virsh pool-undefine pool
Pool pool has been undefined

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes     

Scenario-4: Create 'fc_host' type pool 
1. Prepare the xml file used to define the pool
# cat pool-1.xml 
<pool type='scsi'>
  <name>pool-1</name>
  <source>
    <adapter type='fc_host' managed='yes' wwnn='1001001b32a9da4e' wwpn='1101001b32a9da4e'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
    </permissions>
  </target>
</pool>

2. Define and start the pool and that will generate new vHBA
# virsh pool-define pool-1.xml 
Pool pool-1 defined from pool-1.xml

# virsh pool-build pool-1
Pool pool-1 built

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

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

# virsh nodedev-list fc_host
scsi_host1
scsi_host16
scsi_host8

3. Destroy and undefine the pool and the vHBA will disappears
# virsh pool-destroy pool-1
Pool pool-1 destroyed

# virsh nodedev-list fc_host
scsi_host1
scsi_host8

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes       
 pool-1               inactive   no        

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

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes    

All the results are as expected, move this bug to be verified.

Comment 9 errata-xmlrpc 2018-04-10 10:46:43 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://access.redhat.com/errata/RHEA-2018:0704