Re: [PATCH] storage_scsi: Handle physical HBA when deleting vHBA vport.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 04/15/2016 10:11 AM, Nitesh Konkar wrote:
> Thanks John for the reply.
> 
> On Fri, Apr 15, 2016 at 5:08 PM, John Ferlan <jferlan@xxxxxxxxxx> wrote:
> 
>>
>>
>> On 04/07/2016 05:09 AM, Nitesh Konkar wrote:
>>> HBA will get treated as vHBA if not returned
>>> after detecting vhba_parent format.
>>>
>>> Signed-off-by: Nitesh Konkar <nitkon12@xxxxxxxxxxxxxxxxxx>
>>> ---
>>> Before Patch:
>>> # virsh pool-destroy poolhba_name
>>> error: Failed to destroy pool poolhba_name
>>> error: internal error: Invalid adapter name 'pci_000x_0x_00_x' for SCSI
>> pool
>>>
>>> # virsh nodedev-dumpxml scsi_host2
>>> <device>
>>>   <name>scsi_host2</name>
>>>   <path>xxxx</path>
>>>   <parent>pci_000x_0x_00_x</parent>
>>>   <capability type='scsi_host'>
>>>     <host>2</host>
>>>     ...
>>>     ...
>>>     <capability type='vport_ops'>
>>>       <max_vports>255</max_vports>
>>>       <vports>0</vports>
>>>     </capability>
>>>   </capability>
>>> </device>
>>>
>>> After Patch:
>>> # virsh pool-destroy poolhba_name
>>> Pool poolhba_name destroyed
>>>
>>>  src/storage/storage_backend_scsi.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>
>> Can you provide the pool-dumpxml for poolhba_name? Can you provide the
>> nodedev-dumpxml of the 'scsi_host#' that was created for the vHBA pool?
>>
>>
> This patch is to destroy a pool created out from a Physical HBA. Apologies,
> if the
> commit message was misleading.
> 
>  # virsh pool-dumpxml poolhba_name
> <pool type='scsi'>
>   <name>poolhba_name</name>
>   <uuid>60d74134-0c18-4d4f-9305-24d96ce1a1b6</uuid>
>   <capacity unit='bytes'>268435456000</capacity>
>   <allocation unit='bytes'>268435456000</allocation>
>   <available unit='bytes'>0</available>
>   <source>
>     <adapter type='fc_host' managed='yes' wwnn='20000120fa8f1271'
> wwpn='10000090fa8f1271'/>
>   </source>
>   <target>
>     <path>/dev/disk/by-id</path>
>     <permissions>
>       <mode>0700</mode>
>       <owner>0</owner>
>       <group>0</group>
>     </permissions>
>   </target>
> </pool>
> 

OK, maybe I wasn't clear enough... Which 'scsi_host#' is *this* pool
associated with. Prior to creating it, do a virsh nodedev-list
scsi_host.  Then create it. Then generate the list again.

Or of course since you cannot delete the poolvhba_name, go through the
various scsi_host#'s on your host looking for the one with the match
wwwn/wwpn - then do the nodedev-dumpxml of that.  For you example you
are looking for the scsi_host# with the matching wwnn='20000120fa8f1271'
and wwpn='10000090fa8f1271'.

That one is supposed to list 'scsi_host2' in the <parent> field as my
'scsi_host19' does below.


John

> virsh nodedev-dumpxml scsi_host2
> <device>
>   <name>scsi_host2</name>
> 
> <path>/sys/devices/pci0001:00/0001:00:00.0/0001:01:00.0/0001:02:09.0/0001:09:00.1/host2</path>
>   <parent>pci_0001_09_00_1</parent>
>   <capability type='scsi_host'>
>     <host>2</host>
>     <unique_id>1</unique_id>
>     <capability type='fc_host'>
>       <wwnn>20000120fa8f1271</wwnn>
>       <wwpn>10000090fa8f1271</wwpn>
>       <fabric_wwn>100050eb1a99d430</fabric_wwn>
>     </capability>
>     <capability type='vport_ops'>
>       <max_vports>255</max_vports>
>       <vports>0</vports>
>     </capability>
>   </capability>
> </device>
> 
> 
> Something just doesn't seem right. The 'parent' is optional and the path
>> you're changing is for the case when the XML doesn't provide the parent.
>> Thus on delete we have to look up the parent based upon the wwwn/wwpn of
>> the vHBA.  From that, we grab the 'parent' field in order to
>> automagically remove the vHBA.
>>
>>
> 
>> For example, if I have:
>>
>> # cat vhbapool_noparent.xml
>>     <pool type='scsi'>
>>       <name>vhbapool_noparent</name>
>>       <source>
>>         <adapter type='fc_host' wwnn='5001a4aea69b98a3'
>> wwpn='5001a4ac3f71c7e1'/>
>>       </source>
>>       <target>
>>         <path>/dev/disk/by-path</path>
>>         <permissions>
>>           <mode>0700</mode>
>>           <owner>0</owner>
>>           <group>0</group>
>>         </permissions>
>>       </target>
>>     </pool>
>>
>>
>> Then the code will search for HBA's that are capable of supporting vhost
>> (e.g., they have the vport_ops).  In my case, that's scsi_host3:
>>
>> # virsh nodedev-dumpxml scsi_host3
>> <device>
>>   <name>scsi_host3</name>
>>   <path>/sys/devices/pci0000:00/0000:00:04.0/0000:10:00.0/host3</path>
>>   <parent>pci_0000_10_00_0</parent>
>>   <capability type='scsi_host'>
>>     <host>3</host>
>>     <unique_id>0</unique_id>
>>     <capability type='fc_host'>
>>       <wwnn>20000000c9848140</wwnn>
>>       <wwpn>10000000c9848140</wwpn>
>>       <fabric_wwn>2002000573de9a81</fabric_wwn>
>>     </capability>
>>     <capability type='vport_ops'>
>>       <max_vports>127</max_vports>
>>       <vports>5</vports>
>>     </capability>
>>   </capability>
>> </device>
>>
>>
>> I can start the pool:
>>
>> # virsh pool-create vhbapool_noprent.xml
>> Pool vhbapool_noparent created from vhbapool_noparent.xml
>>
>> If I look at the list of scsi_host's:
>>
>> # virsh nodedev-list scsi_host
>> scsi_host0
>> scsi_host1
>> scsi_host15
>> scsi_host16
>> scsi_host17
>> scsi_host19
>> scsi_host2
>> scsi_host3
>> scsi_host4
>> scsi_host5
>>
>> I can "assume" the one with the highest number is my vHBA and then dump
>> it's XML:
>>
>> # virsh nodedev-dumpxml scsi_host19
>> <device>
>>   <name>scsi_host19</name>
>>
>>
>> <path>/sys/devices/pci0000:00/0000:00:04.0/0000:10:00.0/host3/vport-3:0-14/host19</path>
>>   <parent>scsi_host3</parent>
>>   <capability type='scsi_host'>
>>     <host>19</host>
>>     <unique_id>16</unique_id>
>>     <capability type='fc_host'>
>>       <wwnn>5001a4aea69b98a3</wwnn>
>>       <wwpn>5001a4ac3f71c7e1</wwpn>
>>       <fabric_wwn>2002000573de9a81</fabric_wwn>
>>     </capability>
>>   </capability>
>> </device>
>>
>> Which it is since the 'wwnn' and 'wwpn' match.  Note the "<parent>" in
>> this case is "scsi_host3" (just like I assumed earlier).
>>
>> When we go to delete the vHBA, the deleteVport code will do this lookup
>> for us and remove the parent scsi_host#
>>
>> # virsh pool-destroy vhbapool_noparent
>> Pool vhbapool_noparent destroyed
>>
>> # virsh nodedev-list scsi_host
>> scsi_host0
>> scsi_host1
>> scsi_host15
>> scsi_host16
>> scsi_host17
>> scsi_host2
>> scsi_host3
>> scsi_host4
>> scsi_host5
>>
>> #
>>
>> So can you show me what's different with the configuration you have that
>> the <parent> for the vHBA is not prefixed with scsi_host. Is there
>> perhaps a way to determine what the 'scsi_host#' is that was created for
>> the vHBA? (since it should be removed).
>>
>> Thanks -
>>
>> John
>>> diff --git a/src/storage/storage_backend_scsi.c
>> b/src/storage/storage_backend_scsi.c
>>> index e6c8bb5..dd0343f 100644
>>> --- a/src/storage/storage_backend_scsi.c
>>> +++ b/src/storage/storage_backend_scsi.c
>>> @@ -842,6 +842,11 @@ deleteVport(virConnectPtr conn,
>>>          if (!(vhba_parent = virStoragePoolGetVhbaSCSIHostParent(conn,
>> name)))
>>>              goto cleanup;
>>>
>>> +        if (STRPREFIX(vhba_parent, "pci")) {
>>> +            ret = 0;
>>> +            goto cleanup;
>>> +        }
>>> +
>>>          if (virGetSCSIHostNumber(vhba_parent, &parent_host) < 0)
>>>              goto cleanup;
>>>      }
>>>
>>
> Looking forward for your comments.
> 
> Warm Regards,
> Nitesh Konkar.
> 

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]