On Thu, Jul 31, 2008 at 11:34:48AM -0400, David Lively wrote:

Hi Folks -

I see Daniel Berrange submitted a SCSI HBA storage backend in March. What ever happened to that? I'd be happy to pick this up if there's more work to do (is there a code base later than the posted patch?)

One outstanding question was one of naming. I used the directory name under /sys/class/scsi_host/ for naming of HBAs, eg 'host3'. This is Linux specific, but not neccessarily a problem if we can easily map names to the host device enumeration APIs to match up the PCI devices associated with the HBA. I decided I'd rather wait until I had the host device enumeration APIs done before formally deciding on the SCSI storage pool terminology, but never got around to doing that. The second question was how best to deal with NPIV - this is essentially identical to SCSI HBA, but with ability to create & delete HBAs on the fly given a suitable 'parent' HBA.

In the longer run, I'm looking towards adding support necessary for FC environments (like multipath). Also, it seems (to my iSCSI-ignorant mind) that iSCSI should be just another flavor of the SCSI driver (kind of like netfs is a flavor of the fs driver ...). Is anyone working on such a refactoring?

Unfortunately iSCSI is a rather complicated beast and can't easily be dealt with in the same way as SCSI from userspace. Even on Linux under sysfs, SCSI HBAs and iSCSI targets appear in different places so I feel its best to keep the separation of storage pools for the two of them. There may be a couple of specific funtions we could split out in a shared file though - enumerating LUNs from sysfs might be something we can share. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|