Pete Wyckoff wrote:
> [EMAIL PROTECTED] wrote on Thu, 22 May 2008 16:58 -0500:
>> 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 added "-I iser" to discovery (or "-I default") and things work
> again. Thanks for the multiple suggestions. My usage model is to
> do one-at-a-time login into targets for which I know exactly what
> addresses, names, and transport types should be used.
>
> Functionally, it does save a step, but I'm a bit bothered by
> having to choose the transport type at discovery time. It's not
> obvious to new iser users that discovery always uses the TCP
> transport. Forcing the use of "-I iser" there might add to their
> confusion.
>
> A bit weird to have to run re-discovery to switch the transport
> type, when you know you'll find exactly the same discovered targets,
> too. In theory I might like to connect up an iser and a tcp to the
> same target, at the same time, although possibly to different LUNs.
>
So how does that work with tgt and other targets? I have been creating
one target then doing a iser portal at ip1 then a tcp portal at ip2, so
I have to run discovery twice for each portal.
I am thinking there have to be targets where we will just do discovery
to one address and it will tell us about both. Can you do this with tgt?
But you can still bind after discovery. If you do discovery with no -I,
then on a portal that is already discovered do:
iscsiadm -m node -P 1
Target: iqn.1992-08.com.netapp:sn.33615311
Portal: 10.15.84.19:3260,2
Iface Name: default
iscsiadm -m node -T iqn.1992-08.com.netapp:sn.33615311 -p 10.15.84 -I
iser -o new
iscsiadm -m node -P 1
Target: iqn.1992-08.com.netapp:sn.33615311
Portal: 10.15.84.19:3260,2
Iface Name: default
Iface Name: iser
Portal: 10.15.85.19:3260,3
Iface Name: default
Iface Name: iser
There is one problem with that where you would have two bindings setup.
One for the default from the original discovery command and one for -o
new iser command and you have to manually -o delete the default one.
Or maybe in the end I will just add compat for the node mode
iface.transport back.
>> 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.
>
> I generally don't like it when anything happens automatically. :)
> For the IB case, we run discovery using TCP on IPoIB, and sometimes
> want to run data over IPoIB too. Trying to use iser if an IB card
> is present is not always the right thing to do. So please always
> default to TCP.
>
> For the iscsi offload case, I'm guessing these devices also allow
> you to run normal non-offloaded IP over them too, in which case I'd
> apply a similar argument. Although I see your point about users
> just wanting to use their hardware directly, without needing to
> specify what type it is.
>
> You could always do the automagic in the init script, rather than in
The init script will not work so well, because you run the discovery
command from iscsiadm so at that time users will expect everything
setup. But yeah if we did it like linux-iscsi we could do it from the
init scripts.
> iscsiadm, and us hands-on types can continue to use our own custom
> init scripts.
>
> [in another mail]
>> Oh yeah the userspace tools from 869.2 should work with
>> 2.6.26-rc3.
>
> This is important, thanks. Userspace git head fails with stock
> 2.6.26-rc3 due to the introduction of
> ISCSI_UEVENT_CREATE_BOUND_SESSION in "pass ep to session
> creation". Guess I should pull in your git kernel tree too.
>
It should not fail. We should drop down to the old behavior. I will
check that out. I think I forgot to copy over a fix from tcp to iser for
compat support.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
