Re: [libvirt] [PATCH 1/1] Merge DanPB's SCSI HBA pool code

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....

> 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.

> +/* > + * 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.

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.