https://bugzilla.redhat.com/show_bug.cgi?id=1171933
After processing all the LU's and find no "real" LU's - check if
perhaps
the cause of that was a poorly formed 'target.path'. The expection is
generally that the path is /dev/disk/by-path or at least something in /dev.
Although it's not impossible for the user to provide something. If they
do provide something it should be valid or we should just cause a failure
to start the pool with an appropriate message.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/storage/storage_backend_scsi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c
index 2f1f5ed..c3a1892 100644
--- a/src/storage/storage_backend_scsi.c
+++ b/src/storage/storage_backend_scsi.c
@@ -467,6 +467,15 @@ virStorageBackendSCSIFindLUsInternal(virStoragePoolObjPtr pool,
if (!*found)
VIR_DEBUG("No LU found for pool %s", pool->def->name);
+ if (!*found && !virFileExists(pool->def->target.path) &&
+ !STRPREFIX(pool->def->target.path, "/dev")) {
+ virReportError(VIR_ERR_INVALID_ARG,
+ _("No LUs found for pool '%s' target "
+ "path '%s' not found"),
+ pool->def->name, pool->def->target.path);
+ retval = -1;
+ }
+
closedir(devicedir);
return retval;
--
2.1.0