Daniel P. Berrange wrote:
On Fri, Jan 16, 2009 at 12:21:05PM -0600, Mike Christie wrote:
Daniel P. Berrange wrote:
- No API for enumerating the LUNs in a target once you're logged in ?
open-iscsi / iscsiadm does not do this, it merely creates a virtual scsi
adapter and then the generic kernel scsi code does this (AFAIK).
iscsiadm has a command to at least list the LUNs from an active target
though not providing the corresponding device names. Getting this info
is one of the more tedious things, because poking around in sysfs to
find the devices matching the LUNs is very troubleprone due to changing
structure of sysfs, and changing output of iscsiadm. Having an API for
listing LUNS and their device paths would be very valuable.
What are you guys going for other transport like Fibre Channel? I am
asking because I was thinking we need a more generic tool/lib that would
handle this type of thing for all transports.
We haven't comimtted our FC support yet, but our proof of concept works
thus...
- User supplies an HBA name (name format TBD, currently just sysfs
name, eg "host0").
- Iterate over /sys/class/scsi_host/$HBA/device to read list of LUNs/devs
corresponding to the HBA.
We don't support LUN creation/deletion for this, since again, AFAIK theres
no API / tool for this in general - only closed source vendor specific
apps.
We also intend to add NPIV support, which is simply a matter of getting
a desired WWPN:WWNN from the user, and echoing this into right place
in sysfs. vHBA appears, repeat above code for enumerating it LUNs. To
kill off the vHBA, just echo the WWPN:WWNN into sysfs again.
All much easier than iSCSI really.
I think you really need some FC hardware.
iSCSI and FC should be the same. At least I mean they could be the same
for many cases. With NPIV I think it will differ. For FC with NPIV I
think the sysfs layout is going to be different. You would have a scsi
host as the parent of a virtual scsi host so the above would not work.
But for RHEL5 normally for iscsi or FC for this:
> - User supplies an HBA name (name format TBD, currently just sysfs
> name, eg "host0").
for iscsi or fc they both have a /sys/class/scsi_host/hostX.
In this host dir they both have a device link/dir. In that dir, for
iscsi you would have a iscsi_host:hostX link and then you would have a
dir for the iscsi sessions like this:
[mnc@dozer-02 device]$ ls
iscsi_host:host8 power scsi_host:host8 session6 uevent
You would then go to the session dir which is actually
/sys/clsss/iscsi_session/session6
(depending on the kernel version (not within RHEL5 but in newer upstream
kernels) this is the real dir and so there is no device link).
In Fibre channel you have a similar layout as iscsi in the host dir and
you cannot just read the luns from the host's device dir. You have
something similar to iscsi, but you should have fc_host:hostX dir and a
dir for each rport like this:
[mnc@dozer-02 device]$ ls
fc_host:host9 power scsi_host:host9 rport0 uevent
For FC you would then go to the rport (in kernels RHEL5 and newer you
have a rport which is between the host and target) dirs and in there you
have a target dir like with iscsi, and then you have to go to the target
dir to scan for luns like you would with iscsi.
For RHEL4 the FC layout is different and I do not think you have the
rport dir in the host's one. Instead you would have the target one right
there. This is because in RHEL4 we have a fc_transport instead of rport
and the fc_transport attaches to the target instead of adding itself
between the host and target like is done in RHEL5 and current kernels.
For RHEL4 iSCSI also has a different layout that is more like FC in
RHEL4 because there is not iscsi_session and instead you just have the
target dirs right in the host ones.
So depending on what kernels you want to support and what features you
are going to support FC is going to be a mess too :) iSCSI basically
followed FC's lead with the sysfs changes. The difference is that iscsi
calls it struct between the host and target a iscsi_session and in FC it
is the rport.
There is one nicer simplification with FC though if the user gives you
an rport then the first number in there is the host number and so you
can easily find the host with that. With iscsi the sid is not the host
number, so you have to go to the iscsi_session dir and get this from the
device link (due to driver model and sysfs changes though this is a pain
to do across kernels I think).
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
