On Fri, Oct 30, 2015 at 11:13:21AM -0400, John Ferlan wrote:
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>
---
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;
}
This change is unrelated to the other one. Also, is this warning really
needed? I think leaving the format as 'unknown' is visible enough.
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;
Adding the VIR_STORAGE_VOL_OPEN_NOERROR flag and propagating it down to
virStorageBackendDetectBlockVolFormatFD would be nicer.
That way it can return -2 on EIO if the flag is present without spamming
the logs. The other functions called by virStorageBackendUpdateVolInfo
can also return -1 on a fatal error that way (although there do not seem
to be any functions that could fail with NOERROR at the moment).
Jan