Daniel P. Berrange wrote:
On Fri, Feb 20, 2009 at 05:14:55PM -0500, David Allan wrote:
Last March, DanPB posted code to create pools from SCSI HBAs. This patch is simply bringing that code into the current tree.
* src/storage_backend_scsi.[ch] contain the pool implementataion
* There are small changes to several other source files to integrate the new pool type.
@@ -876,6 +879,13 @@ if test "$with_storage_iscsi" = "yes" -o "$with_storage_iscsi" = "check"; then
fi
AM_CONDITIONAL([WITH_STORAGE_ISCSI], [test "$with_storage_iscsi" = "yes"])
+if test "$with_storage_scsi" = "check"; then
+ with_storage_scsi=yes
+
+ AC_DEFINE_UNQUOTED([WITH_STORAGE_SCSI], 1,
+ [whether SCSI backend for storage driver is enabled])
+ AM_CONDITIONAL([WITH_STORAGE_SCSI], [test "$with_storage_scsi" = "yes"])
+fi
This isn't quite right, because the code depends on HAL but we're
not checking for it here.
There are other checks in configure.ac that look for HAL, but they
are not neccessarily enabled based on the same flags. But see my
comments later about whether we should just avoid HAL....
Per your later comments, let's just avoid HAL.
diff --git a/src/Makefile.am b/src/Makefile.am
index 3a798d2..f1dd789 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -9,6 +9,7 @@ INCLUDES = \
$(XEN_CFLAGS) \
$(SELINUX_CFLAGS) \
$(DRIVER_MODULE_CFLAGS) \
+ $(POLKIT_CFLAGS) \
This isn't related to HAL or SCSI drivers.
+/**
+ * virStorageBackendSCSIRefreshPool:
+ *
+ * Query HAL for all storage devices associated with a specific
+ * SCSI HBA.
+ *
+ * XXX, currently we only support regular devices in /dev/,
+ * or /dev/disk/by-XXX. In future we also need to be able to
+ * map to multipath devices setup under /dev/mpath/XXXX.
+ */
+static int
+virStorageBackendSCSIRefreshPool(virConnectPtr conn,
+ virStoragePoolObjPtr pool)
+{
In this method we basically have a HBA number, and ask HAL for
all devices which are children of this. We still have a whole
bunch of code in the virStorageBackendSCSIAddLUN() which is
called per device we find, that pokes around in sysfs to get
out more metadata. We also have similar, but different code
in the iSCSI code that pokes around in sysfs.
Further more HAL is deprecated for dealing with storage devices
in Fedora 10 and later, with DeviceKit targetted to take over
its role. It is a bit of a mess really. I'm inclined to say
thta we should not use HAL for this SCSI stuff at all, and
instead we should slightly generalize our existing iSCSI method
virStorageBackendISCSIFindLUNs() so that it works for both the
SCSI and iSCSI storage pools, letting us share the code.
That sounds good to me. The important thing to me is that we
consolidate, and if HAL is not the way to go, then I'm fine with
generalizing the existing iSCSI method.
I'll break it out so that a) we can change it easily in the future and
b) non-Linux platforms can implement something to make it work without
having to modify any other code.
[snipped a bunch of patch]
+/*
+ * vim: set tabstop=4:
+ * vim: set shiftwidth=4:
+ * vim: set expandtab:
+ */
+/*
+ * Local variables:
+ * indent-tabs-mode: nil
+ * c-indent-level: 4
+ * c-basic-offset: 4
+ * tab-width: 4
+ * End:
+ */
We've since decided against adding these editor footers.
I'll remove them.
The virStorageBackendISCSIFindLUNs() method currently takes an iSCSI
session name and uses that to find the host:bus:target prefix for the
virtual iSCSI HBA, then scans for LUNS with that prefix.
If we split this into 2 methods, the first
virStorageBackendISCSIFindLUNsForSession()
Just does the session -> host:bus:target lookup, then calling
virStorageBackendSCSIFindLUNs(int host, int bus, int target)
which does the scan matching /sys/bus/scsi/host:bus:target:lun to find
the LUNs. Then, this new SCSI pool would merely need a short piece of
code to call virStorageBackendSCSIFindLUNs() and avoid all this HAL
stuff.
I'll put that together and send a revised patch that incorporates your
comments as well as Jim's.
Dave
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list