[libvirt] [PATCH 00/11] Allow creation of vHBA by parent_wwnn/wwpn or fabric_name

Jim Fehlig jfehlig at suse.com
Tue Dec 13 00:50:05 UTC 2016

On 12/03/2016 07:09 AM, John Ferlan wrote:
> ping?

Sorry, I seem to have lost your initial cover letter so responding here...

> On 11/18/2016 09:26 AM, John Ferlan wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1349696
>> Lots of details in the bz, but essentially the problem is that providing
>> a "parent" scsi_hostX value has drawbacks on reboots because what was
>> scsi_hostX could turn into scsi_hostY on subsequent reboots.
>> So add the ability to use the parent wwnn/wwpn or fabric_wwn as 'search'
>> criteria in order to create either non persistent vHBA's via nodedev or
>> persistent vHBA's via storage pools.

I've not looked at all the patches in detail, but I have been giving them a fair 
bit of testing and haven't noticed any problems thus far.

Once question I do have is related to volume detection in vport-based pools. 
Currently when there are multiple paths to a LUN only the active ones are 
displayed in the pool. Inactive paths are ignored since saferead() fails in 
src/storage/storage_backend.c:virStorageBackendDetectBlockVolFormatFD(). Without 
the inactive paths, there would be no path to the LUN if it was trespassed. I 
made the below hack to virStorageBackendUpdateVolTargetInfo() to show the 
inactive paths too, and was able to pass those to the guest allowing it to 
handle multipathing. Is there a reason the inactive paths are ignored?


Index: libvirt-2.5.0/src/storage/storage_backend.c
--- libvirt-2.5.0.orig/src/storage/storage_backend.c
+++ libvirt-2.5.0/src/storage/storage_backend.c
@@ -1941,8 +1941,11 @@ virStorageBackendUpdateVolTargetInfo(vir

      if (withBlockVolFormat) {
          if ((ret = virStorageBackendDetectBlockVolFormatFD(target, fd,
-                                                           readflags)) < 0)
+                                                           readflags)) < 0) {
+            if (ret == -2)
+                ret = 0;
              goto cleanup;
+        }


More information about the libvir-list mailing list