iscsi offload on rh el based servers guide?

Gianluca Cecchi gianluca.cecchi at gmail.com
Sat May 15 02:06:45 CDT 2010


On Fri, May 14, 2010 at 10:52 PM, Shyam Iyer <shyam_iyer at dell.com> wrote:

> [snip]
>
>
> But if you are using static addresses then you need to add them yourself
> and different from the normal interface to avoid arp cache reference
> problems..
>
>
>
>  2) Do the nic has to be configured anyway to start in
> /etc/sysconfig/network-scripts/ifcfg-eth0?
> With something like this for example if without an ip:
>  # Broadcom Corporation NetXtreme II BCM57711 10-Gigabit PCIe
> DEVICE=eth0
> HWADDR=00:10:18:58:E8:F8
> ONBOOT=yes
> BOOTPROTO=static
> TYPE=Ethernet
> MTU=9000
>
>  The discovery happens though the normal ethernet interface so you can
> configrue the eth interface through the usual ways.
>
>
>
Thanks for answering.
So this seems to confirm the correctness of my base config: an ip assigned
to the eth interface and a different ip assigned to the  bnx2i.<mac> iscsi
interface.


>  3) Can I set MTU=9000 if using offload scsi? Is it supported?
> If I don't have instead to set the nic to start at boot, where to put the
> mtu parameter?
>
>  That doesn't make a difference to the offload interface as this is only
> for the eth interface.
>

In the sense that if I'm using iscsi offload I can't use jumbo frames?


>
> If I now try to connect with the other card ending fb mac .175 ip for eth1
> and .179 for the iscsi part):
>  # iscsiadm --mode node --portal 10.10.100.30:3260 -I
> bnx2i.00:10:18:58:e8:fb --login
> Logging in to [iface: bnx2i.00:10:18:58:e8:fb, target:
> iqn.2001-05.com.equallogic:0-8a0906-97d4b5e06-596000000264bc83-blg9-vol3,
> portal: 10.10.100.30,3260]
> Logging in to [iface: bnx2i.00:10:18:58:e8:fb, target:
> iqn.2001-05.com.equallogic:0-8a0906-8904b5e06-b66000000204bc83-blg9-vol1,
> portal: 10.10.100.30,3260]
> Logging in to [iface: bnx2i.00:10:18:58:e8:fb, target:
> iqn.2001-05.com.equallogic:0-8a0906-94c4b5e06-df9000000234bc83-blg9-vol2,
> portal: 10.10.100.30,3260]
> iscsiadm: Could not login to [iface: bnx2i.00:10:18:58:e8:fb, target:
> iqn.2001-05.com.equallogic:0-8a0906-97d4b5e06-596000000264bc83-blg9-vol3,
> portal: 10.10.100.30,3260]:
> iscsiadm: initiator reported error (4 - encountered connection failure)
> iscsiadm: Could not login to [iface: bnx2i.00:10:18:58:e8:fb, target:
> iqn.2001-05.com.equallogic:0-8a0906-8904b5e06-b66000000204bc83-blg9-vol1,
> portal: 10.10.100.30,3260]:
> iscsiadm: initiator reported error (4 - encountered connection failure)
> iscsiadm: Could not login to [iface: bnx2i.00:10:18:58:e8:fb, target:
> iqn.2001-05.com.equallogic:0-8a0906-94c4b5e06-df9000000234bc83-blg9-vol2,
> portal: 10.10.100.30,3260]:
> iscsiadm: initiator reported error (4 - encountered connection failure)
>
>  It is a good idea to discover for the other iface as well to create a new
> node record for the interface
>
> #iscsiadm -m discovery -t st -p 10.10.100.30:3260 -I
> bnx2i.00:10:18:58:e8:fb
> and then login
>
> # iscsiadm --mode node --portal 10.10.100.30:3260 -I
> bnx2i.00:10:18:58:e8:fb --login
>
>
> -Shyam Iyer
> Dell Linux Engineering
>

Yes, but it is indeed what I did.
As I wrote in my previous post, the discovery correctly happens for both the
bnx2i.<MAC> interfaces. And in fact

 iscsiadm -m node -P1

gives for example
Target:
iqn.2001-05.com.equallogic:0-8a0906-97d4b5e06-596000000264bc83-blg9-vol3
Portal: 10.10.100.30:3260,1
Iface Name: bnx2i.00:10:18:58:e8:f9
Iface Name: bnx2i.00:10:18:58:e8:fb

They are both listed.
But the login command fails if the other one has already done the log in.
In fact I can reverse with the same results.
I can log out the bnx2i.00:10:18:58:e8:f9, then log in
the bnx2i.00:10:18:58:e8:fb and it succeeds.
But at this point if I try to login again with the bnx2i.00:10:18:58:e8:f9
it gets the connection error too....

Is this expected?
Because with sw iscsi through the eth interaces this doesn't happen.

Can it be a routing problem, as I seem to have seen in another post before?

In the sense that when I try to login through a bnx2i interface , perhaps it
tries to arrive to the portal through the other eth interface and gets the
error?
In such case do I have to any chance to set up routes to solve the problem?

Thanks Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20100515/0167ceb2/attachment.htm 


More information about the Linux-PowerEdge mailing list