ISCSI und Root Partitionen

[lordchaos]

Hallo zusammen,

ich verzweifle hier gerade an Iscsi. Folgende Gegebenheiten:

QNAP TS870 mit mehreren Platten. Auf diesem ist eine Freigabe als ISCSI gegeben.
Ein Rechner welcher über SSD Bootet und /var und /tmp auf dem ISCSI auslagern soll.

Nach dem starten der experten Installation kann ich über das Menü das NAS mit dem ISCSI ansprechen und Partitionen usw. anlegen. Soweit kein Problem.

Beim ersten hochfahren bekomme ich dann eine Fehlermeldung, dass der Targetname nicht gesetzt sei. Onkel Google verrät mir, dass das ein alter Bug ist (Beitrag aus 2012, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693558), der anscheinend in der aktuellen testing weiterhin zu bestehen scheint. Die udevs sind nicht so schnell gefüllt wie das System Iscsi starten möchte. Nach Anleitung geändert und siehe da, Neuer Fehler und der ist mein Problem.

Die Netzwerkkarte hat eine vom DHCP bekommen, die Kommunikation mit dem NAS wird aufgebaut aber ich erhalte einen Fehler, das die Verbindung nicht möglich sei weil die Autorisierung nicht stimmen würde. Zusätzlich steht dort auch noch, dass das Interface default down sei... Interessant ist für mich hier, das eine Kommunikation geht (er erhält ja die Ablehnung des Aufbaus) obwohl das Interface angeblich down ist.
Den ganz genauen Wortlaut kann ich leider nicht wiedergeben, weil das System leider nach dem Start an dieser Stelle die Auflösung ändert und ich somit dann nicht mehr hochscrollen kann.....

fsck hält das System wie gewohnt beim Hochfahren an. Gehe ich nun in die Konsole und gebe manuell ein

/etc/init.d/openscsi start

wird ebenfalls die Verbindung aufgebaut und nun klappt auch ohne Probleme die Anmeldung, obwohl ich nichts an den Einstellungen geändert habe

Kompletter Neustart genau das gleiche Spielchen.

Meine suche im Internet ergibt immer nur den oben beschriebenen Bug, der ja gelöst ist, aber nichts über das weitere Problem.

Leider habe ich beim Qnap bisher nicht rausbekommen, wie ich mir dort die Logs vom Iscsi Server anzeigen lassen kann. Messages und syslog sind leider frei von Infos zu diesem Dienst.

Danke schon mal für alle Infos

Steve

[DAS-ICH]

Hi

das scheint ein Bootproblem zu sein und kein Netzwerkproblem. Ich denke mal, dass das /etc/init.d/openscsi Script startet, wenn noch keine Verbindung mit dem NAS steht. Möglicherweise reicht es das Script so anzupassen, bzw die Startnummer im Runlevel zu ändern, dass es erst dann startet, wenn auch eine Verbindung mit dem NAS reel besteht.

MfG

[lordchaos]

Das Netzwerk steht denke ich,

Ich erhalte brav kurz vorher die Meldung, das die IP zugewiesen wurde. und ich sehe auf meine DHCP auch, das vor dem iscsi script die Anfrage kommt. Aus scherz habe ich mal eine 30sec verzögerung in das startscript gesetzt system bleibt brav stehen (dhcp ist vorher angefragt worden) aber gnau das gleiche Problem

Grüsse

Steve

[DAS-ICH]

Hi

dann poste doch mal Deine Config, vielleicht sehen wir etwas was Dir entgangen ist.

Du kannst beim Booten, wenn die Fehlermeldung kommt, mal die Pause-Taste Deiner Tastatur betätigen, dann bleibt alles stehen und Du könntest mal die Meldung abschreiben, nochmaliges Betätigen der Pausetaste und es geht weiter.

MfG

[lordchaos]

Hallo,

welche configs soll ich bereitstellen.

Das mit Pause kannte ich von früher auch, geht aber leider bei mir nicht, der booted durch Konnte man grub nicht mal sagen das er aufruf für aufruf durchgehen soll?

[DAS-ICH]

Hi

stell erstmal die von open-scsi rein.
Bei mir klappt es mit der Pause-Taste, was du noch machen könntest, bootlogd aktivieren, der sollte dann alles mitschreiben, ja nach Konfiguration.

MfG

[lordchaos]

chso was ich aber vor dem halt sehe ist:
session 2 login rejected: Initiator failed authentication with target

interessant ist folgende Zeile:
Connection2:0 to [target iqn-2004-04.com.qnap_ts-870:iscsi.babylon5.db9d96, portal: 192.168.8.17,3260] through [iface: default] is shutdown......

Wieso bekommt er einen reject wenn er angeblich aus ist .....

[DAS-ICH]

Hi

soweit ich das verstehe, ist das eine Zweite Verbindung, berichtige mich wenn ich falsch liege, und diese scheint nicht richtig , oder anders konfiguriert zu sein.

MfG

[lordchaos]

es werden 2 Verbindungen versucht, beide kommt genau das gleich, sprich beide haben soweit ich das beim durchrattern sehe den gleichen fehler. Bei einem erneuten Aufruf von /etc/init.d/openscsi start klappt das dann ohne Probleme....

[DAS-ICH]

Hi

dann lad erstmal die Config hoch.

MfG

[lordchaos]

mach ich sofort, an die muß ich erstmal dran kommen, habe nun was ganz anderes gemacht habe in das local-top script vom initramfs eine 10 minuten Verzögerung reingebaut, somit habe ich genug Zeit das mal durchzulesen also:


IP-Config: eth0:hardware address 00:11:2f:4e:21:7b mtu 1500 DHCP RARP
ip-Config: eth0 guessed broadcast address 192.168.8.255
ip-Config: eth0 complete (dhcp from 192.168.8.2):
adress: 192.168.8.34 broadcast: 192.168.8.255 netmast 255.255.255.0
gateway: 192.168.8.1 dns0: 192.168.8.2 dns1: 192.168.8.1
domain: homenet.foobar.indahouse (konnte ich mir beim configurieren damals nicht verkneiffen )
rootserver: 192.168.8.2 rootpath:
filename :

soweit alles ok sprich Netzwerk ist da

dann startet iscsi

iscsistart: Logging into iqn.2004-04.com.qnap:ts:870:iscsi.babylon5.db9d96 192.168.8.17:3260,1
iscsistart: can not connect to iSCSI daemon (111)!
iscsistart: version 2.0-873
iscsistart: Login faild to authenticate with target iqn.2004-04.com.qnap:ts:870:iscsi.babylon5.db9d96
iscsistart: session 1 login rejected: Initiator failed authentication with target

So soviel erstmal dazu nun muß ich mir mal überlegen wie ich die configfiles auf einen Rechner bekomme von wo aus ich die posten kann und natürlich 10min warten bis er hochfährt

[DAS-ICH]

Hi

welcher Rechner ist 192.168.8.17, ist der auch in Deinem Netzwerk, oder nur ein Tipfehler. Dennoch ist es seltsam das es händisch funktioniert.

MfG

[lordchaos]

192.168.8.34 ist der Client der die Verbindung aufbauen möchte
192.168.8.17 ist der Server der gemounted werden soll

[DAS-ICH]

Hi

was läuft auf dem Qnap eigentlich, kannst Du Dich da via ssh einloggen??

MfG

[lordchaos]

So hier mal die Dateien:
/etc/iscsi/iscsid.conf:

#
# Open-iSCSI default configuration.
# Could be located at /etc/iscsi/iscsid.conf or ~/.iscsid.conf
#
# Note: To set any of these values for a specific node/session run
# the iscsiadm --mode node --op command for the value. See the README
# and man page for iscsiadm for details on the --op command.
#

######################
# iscsid daemon config
######################
# If you want iscsid to start the first time a iscsi tool
# needs to access it, instead of starting it when the init
# scripts run, set the iscsid startup command here. This
# should normally only need to be done by distro package
# maintainers.
#
# Default for Fedora and RHEL. (uncomment to activate).
# iscsid.startup = /etc/rc.d/init.d/iscsid force-start
#
# Default for upstream open-iscsi scripts (uncomment to activate).
iscsid.startup = /usr/sbin/iscsid


#############################
# NIC/HBA and driver settings
#############################
# open-iscsi can create a session and bind it to a NIC/HBA.
# To set this up see the example iface config file.

#*****************
# Startup settings
#*****************

# To request that the iscsi initd scripts startup a session set to "automatic".
# node.startup = automatic
#
# To manually startup the session set to "manual". The default is manual.
node.startup = manual

# For "automatic" startup nodes, setting this to "Yes" will try logins on each
# available iface until one succeeds, and then stop. The default "No" will try
# logins on all availble ifaces simultaneously.
node.leading_login = No

# *************
# CHAP Settings
# *************

# To enable CHAP authentication set node.session.auth.authmethod
# to CHAP. The default is None.
node.session.auth.authmethod = CHAP

# To set a CHAP username and password for initiator
# authentication by the target(s), uncomment the following lines:
#node.session.auth.username = username
#node.session.auth.password = password

# To set a CHAP username and password for target(s)
# authentication by the initiator, uncomment the following lines:
#node.session.auth.username_in = username_in
#node.session.auth.password_in = password_in

# To enable CHAP authentication for a discovery session to the target
# set discovery.sendtargets.auth.authmethod to CHAP. The default is None.
#discovery.sendtargets.auth.authmethod = CHAP

# To set a discovery session CHAP username and password for the initiator
# authentication by the target(s), uncomment the following lines:
#discovery.sendtargets.auth.username = username
#discovery.sendtargets.auth.password = password

# To set a discovery session CHAP username and password for target(s)
# authentication by the initiator, uncomment the following lines:
#discovery.sendtargets.auth.username_in = username_in
#discovery.sendtargets.auth.password_in = password_in

# ********
# Timeouts
# ********
#
# See the iSCSI REAME's Advanced Configuration section for tips
# on setting timeouts when using multipath or doing root over iSCSI.
#
# To specify the length of time to wait for session re-establishment
# before failing SCSI commands back to the application when running
# the Linux SCSI Layer error handler, edit the line.
# The value is in seconds and the default is 120 seconds.
# Special values:
# - If the value is 0, IO will be failed immediately.
# - If the value is less than 0, IO will remain queued until the session
# is logged back in, or until the user runs the logout command.
node.session.timeo.replacement_timeout = 120

# To specify the time to wait for login to complete, edit the line.
# The value is in seconds and the default is 15 seconds.
node.conn[0].timeo.login_timeout = 15

# To specify the time to wait for logout to complete, edit the line.
# The value is in seconds and the default is 15 seconds.
node.conn[0].timeo.logout_timeout = 15

# Time interval to wait for on connection before sending a ping.
node.conn[0].timeo.noop_out_interval = 5

# To specify the time to wait for a Nop-out response before failing
# the connection, edit this line. Failing the connection will
# cause IO to be failed back to the SCSI layer. If using dm-multipath
# this will cause the IO to be failed to the multipath layer.
node.conn[0].timeo.noop_out_timeout = 5

# To specify the time to wait for abort response before
# failing the operation and trying a logical unit reset edit the line.
# The value is in seconds and the default is 15 seconds.
node.session.err_timeo.abort_timeout = 15

# To specify the time to wait for a logical unit response
# before failing the operation and trying session re-establishment
# edit the line.
# The value is in seconds and the default is 30 seconds.
node.session.err_timeo.lu_reset_timeout = 30

# To specify the time to wait for a target response
# before failing the operation and trying session re-establishment
# edit the line.
# The value is in seconds and the default is 30 seconds.
node.session.err_timeo.tgt_reset_timeout = 30


#******
# Retry
#******

# To specify the number of times iscsid should retry a login
# if the login attempt fails due to the node.conn[0].timeo.login_timeout
# expiring modify the following line. Note that if the login fails
# quickly (before node.conn[0].timeo.login_timeout fires) because the network
# layer or the target returns an error, iscsid may retry the login more than
# node.session.initial_login_retry_max times.
#
# This retry count along with node.conn[0].timeo.login_timeout
# determines the maximum amount of time iscsid will try to
# establish the initial login. node.session.initial_login_retry_max is
# multiplied by the node.conn[0].timeo.login_timeout to determine the
# maximum amount.
#
# The default node.session.initial_login_retry_max is 8 and
# node.conn[0].timeo.login_timeout is 15 so we have:
#
# node.conn[0].timeo.login_timeout * node.session.initial_login_retry_max =
# 120 seconds
#
# Valid values are any integer value. This only
# affects the initial login. Setting it to a high value can slow
# down the iscsi service startup. Setting it to a low value can
# cause a session to not get logged into, if there are distuptions
# during startup or if the network is not ready at that time.
node.session.initial_login_retry_max = 8

################################
# session and device queue depth
################################

# To control how many commands the session will queue set
# node.session.cmds_max to an integer between 2 and 2048 that is also
# a power of 2. The default is 128.
node.session.cmds_max = 128

# To control the device's queue depth set node.session.queue_depth
# to a value between 1 and 1024. The default is 32.
node.session.queue_depth = 32

##################################
# MISC SYSTEM PERFORMANCE SETTINGS
##################################

# For software iscsi (iscsi_tcp) and iser (ib_iser) each session
# has a thread used to transmit or queue data to the hardware. For
# cxgb3i you will get a thread per host.
#
# Setting the thread's priority to a lower value can lead to higher throughput
# and lower latencies. The lowest value is -20. Setting the priority to
# a higher value, can lead to reduced IO performance, but if you are seeing
# the iscsi or scsi threads dominate the use of the CPU then you may want
# to set this value higher.
#
# Note: For cxgb3i you must set all sessions to the same value, or the
# behavior is not defined.
#
# The default value is -20. The setting must be between -20 and 20.
node.session.xmit_thread_priority = -20


#***************
# iSCSI settings
#***************

# To enable R2T flow control (i.e., the initiator must wait for an R2T
# command before sending any data), uncomment the following line:
#
#node.session.iscsi.InitialR2T = Yes
#
# To disable R2T flow control (i.e., the initiator has an implied
# initial R2T of "FirstBurstLength" at offset 0), uncomment the following line:
#
# The defaults is No.
node.session.iscsi.InitialR2T = No

#
# To disable immediate data (i.e., the initiator does not send
# unsolicited data with the iSCSI command PDU), uncomment the following line:
#
#node.session.iscsi.ImmediateData = No
#
# To enable immediate data (i.e., the initiator sends unsolicited data
# with the iSCSI command packet), uncomment the following line:
#
# The default is Yes
node.session.iscsi.ImmediateData = Yes

# To specify the maximum number of unsolicited data bytes the initiator
# can send in an iSCSI PDU to a target, edit the following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1) and
# the default is 262144
node.session.iscsi.FirstBurstLength = 262144

# To specify the maximum SCSI payload that the initiator will negotiate
# with the target for, edit the following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1) and
# the defauls it 16776192
node.session.iscsi.MaxBurstLength = 16776192

# To specify the maximum number of data bytes the initiator can receive
# in an iSCSI PDU from a target, edit the following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1) and
# the default is 262144
node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144

# To specify the maximum number of data bytes the initiator will send
# in an iSCSI PDU to the target, edit the following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1).
# Zero is a special case. If set to zero, the initiator will use
# the target's MaxRecvDataSegmentLength for the MaxXmitDataSegmentLength.
# The default is 0.
node.conn[0].iscsi.MaxXmitDataSegmentLength = 0

# To specify the maximum number of data bytes the initiator can receive
# in an iSCSI PDU from a target during a discovery session, edit the
# following line.
#
# The value is the number of bytes in the range of 512 to (2^24-1) and
# the default is 32768
#
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768

# To allow the targets to control the setting of the digest checking,
# with the initiator requesting a preference of enabling the checking, uncomment# one or both of the following lines:
#node.conn[0].iscsi.HeaderDigest = CRC32C,None
#node.conn[0].iscsi.DataDigest = CRC32C,None
#
# To allow the targets to control the setting of the digest checking,
# with the initiator requesting a preference of disabling the checking,
# uncomment one or both of the following lines:
#node.conn[0].iscsi.HeaderDigest = None,CRC32C
#node.conn[0].iscsi.DataDigest = None,CRC32C
#
# To enable CRC32C digest checking for the header and/or data part of
# iSCSI PDUs, uncomment one or both of the following lines:
#node.conn[0].iscsi.HeaderDigest = CRC32C
#node.conn[0].iscsi.DataDigest = CRC32C
#
# To disable digest checking for the header and/or data part of
# iSCSI PDUs, uncomment one or both of the following lines:
#node.conn[0].iscsi.HeaderDigest = None
#node.conn[0].iscsi.DataDigest = None
#
# The default is to never use DataDigests or HeaderDigests.
#

# For multipath configurations, you may want more than one session to be
# created on each iface record. If node.session.nr_sessions is greater
# than 1, performing a 'login' for that node will ensure that the
# appropriate number of sessions is created.
node.session.nr_sessions = 1

#************
# Workarounds
#************

# Some targets like IET prefer after an initiator has sent a task
# management function like an ABORT TASK or LOGICAL UNIT RESET, that
# it does not respond to PDUs like R2Ts. To enable this behavior uncomment
# the following line (The default behavior is Yes):
node.session.iscsi.FastAbort = Yes

# Some targets like Equalogic prefer that after an initiator has sent
# a task management function like an ABORT TASK or LOGICAL UNIT RESET, that
# it continue to respond to R2Ts. To enable this uncomment this line
# node.session.iscsi.FastAbort = No

/etc/iscsi/nodes/iqn.2004-04.com.qnap\:ts-870\:iscsi.babylon5.db9d96/192.168.8.17\,3260\,1/default

node.name = iqn.2004-04.com.qnap:ts-870:iscsi.babylon5.db9d96
node.tpgt = 1
node.startup = automatic
node.leading_login = No
iface.iscsi_ifacename = default
iface.transport_name = tcp
iface.vlan_id = 0
iface.vlan_priority = 0
iface.iface_num = 0
iface.mtu = 0
iface.port = 0
node.discovery_address = 192.168.8.17
node.discovery_port = 3260
node.discovery_type = send_targets
node.session.initial_cmdsn = 0
node.session.initial_login_retry_max = 8
node.session.xmit_thread_priority = -20
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.nr_sessions = 1
node.session.auth.authmethod = CHAP
node.session.auth.username = username (ist richtig gesetzt im original)
node.session.auth.password = userrs_pathword (ist richtig gesetzt im original)
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 15
node.session.err_timeo.lu_reset_timeout = 30
node.session.err_timeo.tgt_reset_timeout = 30
node.session.err_timeo.host_reset_timeout = 60
node.session.iscsi.FastAbort = Yes
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 2
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 192.168.8.17
node.conn[0].port = 3260
node.conn[0].startup = manual
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.conn[0].iscsi.MaxXmitDataSegmentLength = 0
node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
node.conn[0].iscsi.HeaderDigest = None
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No
# END RECORD

[lordchaos]

Auf dem Qnap läuft
iscsid version 2.0-871

[DAS-ICH]

Hi

ändere mal dieses

Code: Alles auswählen

#*****************
# Startup settings
#*****************

# To request that the iscsi initd scripts startup a session set to "automatic".
# node.startup = automatic
#
# To manually startup the session set to "manual". The default is manual.
node.startup = manual

# For "automatic" startup nodes, setting this to "Yes" will try logins on each
# available iface until one succeeds, and then stop. The default "No" will try
# logins on all availble ifaces simultaneously.
node.leading_login = No

in

Code: Alles auswählen

#*****************
# Startup settings
#*****************

# To request that the iscsi initd scripts startup a session set to "automatic".
# node.startup = automatic
#
# To manually startup the session set to "manual". The default is manual.
node.startup = automatic

# For "automatic" startup nodes, setting this to "Yes" will try logins on each
# available iface until one succeeds, and then stop. The default "No" will try
# logins on all availble ifaces simultaneously.
node.leading_login = Yes

Vielleicht ist es das dann schon.

MfG

[lordchaos]

Habe ich in den nodes auch schon geändert und jetzt auch nomal in der hauptconfig. Leider das gleiche Ergebniss..

[DAS-ICH]

Hi

wenn die nodes noch so sind wie Du sie gepostet hast, dann sind noch node.leading_login = No in node.leading_login = Yes und das node.conn[0].startup = manual in das node.conn[0].startup = automatic zu ändern, denke ich.

Mfg

[lordchaos]

nodes_lead_Login hatte ich eben zurückgesetzt zum testen weil ichs in der hauptconf ja ändern sollte das stand vorher auf Yes

das zweite manual habe ich übersehen, hatte immer nur das oben geändert, ABER ergebniss ist das selbe .... Genau der gleiche Fehler...

ich glaube das iface defalut ist falsch, kann das sein? das der default nicht findet, frage ist nur warum

[DAS-ICH]

Hi

denke nicht, da es ja dann manuell auch nicht gehen würde, kannst es natürlich erstmal ändern, in das device welches du nutzen möchtest.

MfG

[lordchaos]

Ok was neues,

wenn ich node.leading.startup auf Yes setzte geht der manualle login auch nicht

[DAS-ICH]

Hi

ich denke mal das soll so sein. Entweder manuell oder automatisch. Schau mal ob du in Deinen Konfigs irgendwo einen Eintrag mit Log oder logging findest, sodass man dort dann mal schauen kann was falsch laufen könnte.

MfG

[lordchaos]

Emm,

ganz blöde frage und wahrscheinlich werden einige die hände über dem kopf zusammenschlagen aber. ich muß doch nicht nach jeder änderung in der config die initramfs neuschreiben oder. nicht das heir mein Denkfehler liegt

[DAS-ICH]

Hi

ich würde erstmal sagen, nein, aber Schaden kann es ja auch nicht.

MfG