On 11/19/2014 03:52 PM, John Ferlan wrote: > 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(-) > Pushed - thanks for the review John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list