Blame SOURCES/libvirt-storage-Add-document-for-possible-problem-on-volume-detection.patch

c401cc
From 1ae3c3fa35e9801b69be59205fa1bf00913c391c Mon Sep 17 00:00:00 2001
c401cc
Message-Id: <1ae3c3fa35e9801b69be59205fa1bf00913c391c.1391001809.git.jdenemar@redhat.com>
c401cc
From: Osier Yang <jyang@redhat.com>
c401cc
Date: Mon, 27 Jan 2014 20:39:30 +0800
c401cc
Subject: [PATCH] storage: Add document for possible problem on volume
c401cc
 detection
c401cc
c401cc
https://bugzilla.redhat.com/show_bug.cgi?id=726797
c401cc
c401cc
For pool which relies on remote resources, such as a "iscsi" type
c401cc
pool, since how long it takes to export the corresponding devices
c401cc
to host's sysfs is really depended, it could depend on the network
c401cc
connection, it also could depend on the host's udev procedures. So
c401cc
it's likely that the volumes are not able to be detected during pool
c401cc
starting process, polling the sysfs doesn't work, since we don't
c401cc
know how much time is best for the polling, and even worse, the
c401cc
volumes could still be not detected or partly not detected even after
c401cc
the polling.  So we end up with a documentation to prompt the fact,
c401cc
in virsh manual.
c401cc
c401cc
And as a small improvement, let's explicitly say no LUNs found in
c401cc
the debug log in that case.
c401cc
(cherry picked from commit 6b29eb848f741742a0f393df40bbcc176520bf27)
c401cc
c401cc
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
c401cc
---
c401cc
 src/storage/storage_backend_scsi.c | 5 +++++
c401cc
 tools/virsh.pod                    | 9 +++++++++
c401cc
 2 files changed, 14 insertions(+)
c401cc
c401cc
diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c
c401cc
index 64b7843..7437488 100644
c401cc
--- a/src/storage/storage_backend_scsi.c
c401cc
+++ b/src/storage/storage_backend_scsi.c
c401cc
@@ -492,6 +492,7 @@ virStorageBackendSCSIFindLUs(virStoragePoolObjPtr pool,
c401cc
     DIR *devicedir = NULL;
c401cc
     struct dirent *lun_dirent = NULL;
c401cc
     char devicepattern[64];
c401cc
+    bool found = false;
c401cc
 
c401cc
     VIR_DEBUG("Discovering LUs on host %u", scanhost);
c401cc
 
c401cc
@@ -513,11 +514,15 @@ virStorageBackendSCSIFindLUs(virStoragePoolObjPtr pool,
c401cc
             continue;
c401cc
         }
c401cc
 
c401cc
+        found = true;
c401cc
         VIR_DEBUG("Found LU '%s'", lun_dirent->d_name);
c401cc
 
c401cc
         processLU(pool, scanhost, bus, target, lun);
c401cc
     }
c401cc
 
c401cc
+    if (!found)
c401cc
+        VIR_DEBUG("No LU found for pool %s", pool->def->name);
c401cc
+
c401cc
     closedir(devicedir);
c401cc
 
c401cc
     return retval;
c401cc
diff --git a/tools/virsh.pod b/tools/virsh.pod
c401cc
index 6b25e99..e866217 100644
c401cc
--- a/tools/virsh.pod
c401cc
+++ b/tools/virsh.pod
c401cc
@@ -2606,6 +2606,15 @@ Refresh the list of volumes contained in I<pool>.
c401cc
 
c401cc
 Start the storage I<pool>, which is previously defined but inactive.
c401cc
 
c401cc
+B<Note>: A storage pool that relies on remote resources such as an
c401cc
+"iscsi" or a (v)HBA backed "scsi" pool may need to be refreshed multiple
c401cc
+times in order to have all the volumes detected (see B<pool-refresh>).
c401cc
+This is because the corresponding volume devices may not be present in
c401cc
+the host's filesystem during the initial pool startup or the current
c401cc
+refresh attempt. The number of refresh retries is dependant upon the
c401cc
+network connection and the time the host takes to export the
c401cc
+corresponding devices.
c401cc
+
c401cc
 =item B<pool-undefine> I<pool-or-uuid>
c401cc
 
c401cc
 Undefine the configuration for an inactive I<pool>.
c401cc
-- 
c401cc
1.8.5.3
c401cc