https://bugzilla.redhat.com/show_bug.cgi?id=1152382 Fix a couple of fc_host SCSI refresh pool issues. The first patch I found while working on the second. It turns out the existing logic to handle 'retval' wasn't correct. Using a default of zero, resulted in a couple of cases where success was returned when it shouldn't have been. The one that caused the issues was when the search of the /sys/bus/scsi/devices/ tree found a new vHBA related device and then "assumed" that the 'block' device would be found in the directory. That assumption resulted in a 10 second pause in virStorageBackendStablePath failing to find a stable path to the device "/dev/(null)" because the getBlockDevice returned zero and a NULL block_device and the processLU code only failed when the return was < 0. The processLU code had similar issues with retval processing which are also fixed. The second patch provides a mechanism to attempt to fill the pool of a libvirt created VPORT_CREATE'd vHBA. The creation takes some time for the udev callback mechanism to find and configure. By adding a thread to attempt to retry to find the LU's (with any luck) after the udev processing has had time to do something means a subsequent 'vol-list' on the pool may actually find a volume without needing to attempt a 'pool-refresh' again. It's too bad the udev mechanism didn't provide a way to indicate it has completed setting up a specific device. John Ferlan (2): storage: Fix issue finding LU's when block doesn't exist storage: Add thread to refresh for createVport src/storage/storage_backend_scsi.c | 147 ++++++++++++++++++++++++++++++++----- 1 file changed, 128 insertions(+), 19 deletions(-) -- 1.9.3 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list