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