https://bugzilla.redhat.com/show_bug.cgi?id=1276198 Prior to commit id '98322052' failure to saferead the block device would cause an error to be logged and the device to be skipped while attempting to discover/create a stable target path for a new LUN (NPIV). This was because virStorageBackendSCSIFindLUs ignored errors from processLU and virStorageBackendSCSINewLun. Ignoring the failure allowed a multipath device with an "active" and "ghost" to be present on the host with the "ghost" block device being ignored. This patch will return a -2 to the caller indicating the desire to ignore the block device since it cannot be used directly rather than fail the pool startup. Additionally, it was found during some debugging that it was possible for the virStorageBackendDetectBlockVolFormatFD to not detect a format, which while not a probably - we probably should at least add some sort of warning message. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- src/storage/storage_backend.c | 4 ++++ src/storage/storage_backend_scsi.c | 7 ++++++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index a375fe0..2de606f 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -1393,6 +1393,10 @@ virStorageBackendDetectBlockVolFormatFD(virStorageSourcePtr target, } } + if (target->format == VIR_STORAGE_POOL_DISK_UNKNOWN) + VIR_WARN("cannot determine the target format for '%s'", + target->path); + return 0; } diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c index a593a2b..d60473d 100644 --- a/src/storage/storage_backend_scsi.c +++ b/src/storage/storage_backend_scsi.c @@ -224,9 +224,14 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr pool, goto cleanup; } + /* Failing to process the format is not fatal - we'll just skip + * this volume. + */ if (virStorageBackendUpdateVolInfo(vol, true, - VIR_STORAGE_VOL_OPEN_DEFAULT) < 0) + VIR_STORAGE_VOL_OPEN_DEFAULT) < 0) { + retval = -2; goto cleanup; + } if (!(vol->key = virStorageBackendSCSISerial(vol->target.path))) goto cleanup;

https://bugzilla.redhat.com/show_bug.cgi?id=1276198 Prior to commit id '98322052' failure to saferead the block device would cause an error to be logged and the device to be skipped while attempting to discover/create a stable target path for a new LUN (NPIV). This was because virStorageBackendSCSIFindLUs ignored errors from processLU and virStorageBackendSCSINewLun. Ignoring the failure allowed a multipath device with an "active" and "ghost" to be present on the host with the "ghost" block device being ignored. This patch will return a -2 to the caller indicating the desire to ignore the block device since it cannot be used directly rather than fail the pool startup. Additionally, it was found during some debugging that it was possible for the virStorageBackendDetectBlockVolFormatFD to not detect a format, which while not a probably - we probably should at least add some sort of warning message. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- src/storage/storage_backend.c | 4 ++++ src/storage/storage_backend_scsi.c | 7 ++++++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index a375fe0..2de606f 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -1393,6 +1393,10 @@ virStorageBackendDetectBlockVolFormatFD(virStorageSourcePtr target, } } + if (target->format == VIR_STORAGE_POOL_DISK_UNKNOWN) + VIR_WARN("cannot determine the target format for '%s'", + target->path); + return 0; }

diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c index a593a2b..d60473d 100644 --- a/src/storage/storage_backend_scsi.c +++ b/src/storage/storage_backend_scsi.c @@ -224,9 +224,14 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr pool, goto cleanup; } + /* Failing to process the format is not fatal - we'll just skip + * this volume. + */ if (virStorageBackendUpdateVolInfo(vol, true, - VIR_STORAGE_VOL_OPEN_DEFAULT) < 0) + VIR_STORAGE_VOL_OPEN_DEFAULT) < 0) { + retval = -2; goto cleanup;