RE: Problems accessing virtual disks on MD3000i, was: RE: Design Questions

[Bryan Mclellan]

You mean the preferred controller module on the MD3000i SAN, I assume.

I'd make sure you can ping all of the nodes (four if you have two controllers).
Discover them all via sendtargets and log in to all of them.

 iscsiadm -m discovery -t st -p 192.168.130.101
 iscsiadm -m node -l
 fdisk -l

You should end up with two or four devices (depending on number of 
controllers); one for each virtual disk mapped to that host for each node 
you've logged in to, provided you've removed the Access mapping, which should 
be just fine. Fdisk -l should print a partition table, or lack thereof, for all 
the disks it can read (which should be half of number of nodes)

It took me a while to figure out that I couldn't access the disks via the 
second controller and playing around with iscsiadm a lot is what finally clued 
me in to it. It helped that I already had a test partition on the virtual disk 
created elsewhere so cat '/proc/partitions' revealed that the partition was 
only visible on two of the disk devices not all four.

Bryan

As a side note, I'd double check your subnet configurations on the controllers. 
Each controller should only have one interface on a specific subnet. I don't 
think this is related to your current problem though.

-Original Message-
From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Arturo 
'Buanzo' Busleiman
Sent: Monday, June 02, 2008 12:08 PM
To: open-iscsi@googlegroups.com
Subject: Re: Problems accessing virtual disks on MD3000i, was: RE: Design 
Questions


Hi Bryan,

I changed my setup to only initiate sessions to the primary domain
controller
. This is my dmesg output now:

snip

Apparently, no changes, except that there are no partitions sde through sdg.
hwinfo and fdisk still report the same.

Btw, I also removed the Access DellUtility partition. No difference
either, except that /dev/sdd disappeared :)

Any other ideas?




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

RE: System hanging with MD3000i with Debian Etch

[Bryan Mclellan]

Of the linux servers console? Sure I can dig one up, it's the first two lines 
of the scsi disk sort of display, twice. Something sort of like:

Disk: DELL  Model: MD3000
Blah blah   blah blah

I don't recall exactly what it said, but it wasn't very interesting.

-Original Message-
From: open-iscsi@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Konrad 
Rzeszutek
Sent: Saturday, May 17, 2008 5:52 AM
To: open-iscsi@googlegroups.com
Subject: Re: System hanging with MD3000i with Debian Etch

Can you attach the serial output or a screen shot?


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

System hanging with MD3000i with Debian Etch

[Bryan Mclellan]

I have a debian etch (vmware guest) box running 2.6.18-6-686. With both 
open-iscsi 2.0.730-1etch1 and 2.0.869.2-2 (from sid) the system hangs when 
trying to log in to the MD3000i. Not having done this before I'm fooling around 
with directions from [1] and running:

iscsiadm --mode discovery --type sendtargets --portal 10.0.9.10
iscsiadm -m node -T 
iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a -p 
10.0.9.10:3260 -l -d 8

and I get [2], where the system locks up after:

Logging in to [iface: default, target: 
iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a, portal: 
10.0.9.10,3260]

Two lines are printed on the console where you can see it's starting to detect 
the disks, where it displays that it's an MD3000i.

MDSM reports:
Date/Time: 5/16/08 2:16:57 PM
Sequence number: 953
Event type: 180D
Description: Session terminated unexpectedly
Event specific codes: 0/0/0
Event category: Internal
Component type: RAID Controller Module Firmware
Component location: None
Logged by: RAID Controller Module in slot 0

Similarly:

# iscsiadm -m node -l
Logging in to [iface: default, target: 
iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a, portal: 
10.0.9.12,3260]
Logging in to [iface: default, target: 
iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a, portal: 
10.0.9.13,3260]
Logging in to [iface: default, target: 
iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a, portal: 
10.0.9.10,3260]
Logging in to [iface: default, target: 
iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a, portal: 
10.0.9.11,3260]

I've added the host on the MD3000i and configured the virtual disk mapping but 
haven't set up any sort of authentication. Does anyone have any tips?

Bryan

[1] http://www.howtoforge.com/iscsi_on_linux
[2] iscsiadm: Max file limits 1024 1024



iscsiadm: exec_node_op: : node 
[iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a,10.0.9.10,3260]
iscsiadm: searching 
iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a

iscsiadm: found 10.0.9.12,3260,2

iscsiadm: iface iter found default.
iscsiadm: updated 'node.name', '' = 
'iqn.1984-05.com.dell:powervault.6001c23000d59fc64754447a'
iscsiadm: updated 'node.tpgt', '-1' = '2'
iscsiadm: updated 'node.startup', 'manual' = 'manual'
iscsiadm: updated 'iface.hwaddress', 'default' = 'default'
iscsiadm: updated 'iface.iscsi_ifacename', 'default' = 'default'
iscsiadm: updated 'iface.net_ifacename', 'default' = 'default'
iscsiadm: updated 'iface.transport_name', 'tcp' = 'tcp'
iscsiadm: updated 'node.discovery_address', '' = '10.0.9.10'
iscsiadm: updated 'node.discovery_port', '0' = '3260'
iscsiadm: updated 'node.discovery_type', 'static' = 'send_targets'
iscsiadm: updated 'node.session.initial_cmdsn', '0' = '0'
iscsiadm: updated 'node.session.initial_login_retry_max', '4' = '4'
iscsiadm: updated 'node.session.cmds_max', '128' = '128'
iscsiadm: updated 'node.session.queue_depth', '32' = '32'
iscsiadm: updated 'node.session.auth.authmethod', 'None' = 'None'
iscsiadm: updated 'node.session.timeo.replacement_timeout', '120' = '120'
iscsiadm: updated 'node.session.err_timeo.abort_timeout', '15' = '15'
iscsiadm: updated 'node.session.err_timeo.lu_reset_timeout', '30' = '20'
iscsiadm: updated 'node.session.err_timeo.host_reset_timeout', '60' = '60'
iscsiadm: updated 'node.session.iscsi.FastAbort', 'Yes' = 'Yes'
iscsiadm: updated 'node.session.iscsi.InitialR2T', 'No' = 'No'
iscsiadm: updated 'node.session.iscsi.ImmediateData', 'Yes' = 'Yes'
iscsiadm: updated 'node.session.iscsi.FirstBurstLength', '262144' = '262144'
iscsiadm: updated 'node.session.iscsi.MaxBurstLength', '16776192' = '16776192'
iscsiadm: updated 'node.session.iscsi.DefaultTime2Retain', '0' = '0'
iscsiadm: updated 'node.session.iscsi.DefaultTime2Wait', '2' = '2'
iscsiadm: updated 'node.session.iscsi.MaxConnections', '1' = '1'
iscsiadm: updated 'node.session.iscsi.MaxOutstandingR2T', '1' = '1'
iscsiadm: updated 'node.session.iscsi.ERL', '0' = '0'
iscsiadm: updated 'node.conn[0].address', '' = '10.0.9.12'
iscsiadm: updated 'node.conn[0].port', '3260' = '3260'
iscsiadm: updated 'node.conn[0].startup', 'manual' = 'manual'
iscsiadm: updated 'node.conn[0].tcp.window_size', '524288' = '524288'
iscsiadm: updated 'node.conn[0].tcp.type_of_service', '0' = '0'
iscsiadm: updated 'node.conn[0].timeo.logout_timeout', '15' = '15'
iscsiadm: updated 'node.conn[0].timeo.login_timeout', '30' = '15'
iscsiadm: updated 'node.conn[0].timeo.auth_timeout', '45' = '45'

iscsiadm: updated 'node.conn[0].timeo.noop_out_interval', '5' = '5'
iscsiadm: updated 'node.conn[0].timeo.noop_out_timeout', '5' = '5'
iscsiadm: updated 'node.conn[0].iscsi.MaxRecvDataSegmentLength', '131072' = 
'131072'
iscsiadm: updated 'node.conn[0].iscsi.HeaderDigest', 'None,CRC32C' = 
'None,CRC32C'
iscsiadm: