Mike Christie wrote:
> Pete Wyckoff wrote:
>> I confess to having lost the plot on the iface rearrangements.  I'm
>> trying to mount up a remote iser target using 2.6.26-rc3 and
>> open-iscsi git HEAD userspace plus hacks to read the new sysfs
>> layout.
>>
>> The old style, before login, was to modify node.transport_name,
>> which now has been changed to live on iface, apparently.  Doing the
>> obvious switch doesn't work:
>>
>>     aib01$ iscsiadm -m node -p 10.100.2.32,3260 --op update \
>>                     -n iface.transport_name -v iser
>>     iscsiadm: Cannot modify iface.transport_name. Use iface mode to 
>> update this value.
>>
> 
> With the git head you can just do
> 
> iscsiadm -m discovery -t st -p ip:port -I iser
> 
> This will setup iser for the portals found. You can then do
> 
> iscsiadm -m node -I iser -l
> 
> to log into all the portals bound to iser or do the normal commands
> 
> iscsiadm -m node -T target -p ip:port -l
> iscsiadm -m node -T target -l
> iscsiadm -m node -T target -I iser -l
> 
> For example f you have a combo of iser and tcp on the target you can do:
> 
> iscsiadm -m node -T target -I iser -l
> 
> to log into the ones bound to iser or
> 
> iscsiadm -m node -T target -I default -l
> 
> to log into the ones bound to tcp (default is for the old tcp no binding).
> 
> The default behavior is broken right now. When you do the discovery 
> command it will bind portals to any module you have loaded so if you 
> have tcp and iser loaded when you do
> 
> iscsiadm -m discovery -t st -p ip:port
> 
> it will bind the portals found to tcp and iser when you probably just 
> want one or the other (iser also loads automatically by the iscsi 
> scripts so it might always be loaded). I was trying to figure out a way 
> to make bnx2i and iser binding easier.
> 

Oh yeah, so let me know what you think would be easier for you? I 
thought just passing in "-I iser" during discovery would be nice and 
save a step. If it is worse then let me know. In the end we will have 
bnx2i, iser, chelsio and tcp, and we will want a quick way to figure out 
what the user wants to do.

I was thinking that when the discovery command is run we could look over 
/sys/class/iscsi_host to see if bnx2i or chelsio had loaded and created 
a scsi/iscsi host for some hba. If it had then it would be safe to 
assume that the user wanted to use the offload engines and so we would 
set the transport to one those modules automatically.

This does not work for tcp or iser where we allocate a host per session. 
For iser maybe if there is a infinniband card then maybe we should 
assume that the user would want to bind to that and we could just do it 
automaitcally for them?

For tcp, if no special hardware is found then we could do the default 
behavior where we just use tcp.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to