[libvirt] [PATCH] storage_scsi: Handle physical HBA when deleting vHBA vport.
Nitesh Konkar
niteshkonkar.libvirt at gmail.com
Fri Apr 15 14:11:28 UTC 2016
Thanks John for the reply.
On Fri, Apr 15, 2016 at 5:08 PM, John Ferlan <jferlan at redhat.com> 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 at linux.vnet.ibm.com>
> > ---
> > 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>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160415/860ec199/attachment-0001.htm>
More information about the libvir-list
mailing list