iSCSI: Unnütze Einträge bzgl. "no route to host" im daemon.log

L

larsen

Active Member
Feb 28, 2020
155
17
38
Hallo,

wir nutzen ein SAN im Zusammenspiel mit Proxmox, welches direkt (ohne Switch) über zwei Kabel am Server angeschlossen ist. Alles funktioniert soweit, aber mir sind störende Einträge im Log aufgefallen, die ich gerne unterbinden würde.

Der Server hat zwei Interfaces für iSCSI. Je eines ist mit je einem Port des SAN verbunden:
  • enp2s0f0, 10.0.3.240 --> 10.0.3.140 (SAN)
  • enp2s0f1, 10.1.3.250 --> 10.1.3.150 (SAN)
Alle 7 Sekunden gibt es folgende Einträge im daemon.log:
Code: 
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.4.170:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.4.170:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.3.140:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.1.100:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.1.100:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.1.110:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.1.110:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.2.130:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.2.130:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.1.3.150:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.2.120:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.2.120:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.4.160:3260 failed (No route to host)
Feb  1 16:35:41 atl-vm04 iscsid: connect to 10.0.4.160:3260 failed (No route to host)

iscsid versucht anscheinend, sich über jedes Interface mit jedem per Discovery entdeckten Portal(?) zu verbinden, was aber nur bei den zwei vorhandenen Verbindungen funktionieren kann. Die Startart ist nur für die zwei Verbindungen auf automatisch gesetzt:
Code: 
atl-vm04:# grep -R startup /etc/iscsi/nodes/iqn.1986-03.com.hp:storage.msa2040.15472745cf | grep autom
./10.0.3.140,3260,5/iscsi_enp2s0f0:node.startup = automatic
./10.1.3.150,3260,6/iscsi_enp2s0f1:node.startup = automatic

Alle 3 Minuten und 38 Sekunden kommt solch ein Eintrag:
Code: 
Feb  1 16:07:46 atl-vm04 pvestatd[1524]: command '/usr/bin/iscsiadm --mode node --targetname iqn.1986-03.com.hp:storage.msa2040.15472745cf --login' failed: exit code 15

Vermutlich möchte sich iscsid mit jedem verfügbaren Portal verbinden, was aber natürlich ohne entsprechende Verbindung nicht funktionieren kann (und auch gar nicht benötigt wird).
Wie kann ich dieses Verhalten deaktivieren?

Ich hatte an Löschen der Einträge in "/etc/iscsi/nodes/iqn.1986-03.com.hp:storage.msa2040.15472745cf" gedacht, aber habe bei meiner Recherche gelesen, dass diese ggf. automatisch wiederhergestellt werden.
Komplett per rsyslog ausfiltern möchte ich die Einträge nicht, weil sie ggf. ja für die existierende Verbindung auftreten könnten, wenn wirklich mal ein Problem besteht.
 
Ich sehe das jetzt gerade erst, da ist das Portbinding aktiviert. Bei vSphere ist das altbekannt und dort durch falsche Einrichtung des iSCSI Adapters geschehen. In der multipath.conf müsste man das anpassen können. Dieses Verhalten wurde bei einer DELL Equalogic immer zwingend benötigt.
Bei klassischem 2 Fabric Setup aber unerwünscht. Ich werde auch mal im Internet suchen wie die Option zu konfigurieren geht.
 
Mein vorheriger Post kann vergessen werden, Linux macht so komische Sachen wie die ESXi Server nicht. ;)
larsen said:
Der Server hat zwei Interfaces für iSCSI. Je eines ist mit je einem Port des SAN verbunden:
  • enp2s0f0, 10.0.3.240 --> 10.0.3.140 (SAN)
  • enp2s0f1, 10.1.3.250 --> 10.1.3.150 (SAN)
Click to expand...
Das sieht gut aus.
larsen said:
iscsid versucht anscheinend, sich über jedes Interface mit jedem per Discovery entdeckten Portal(?) zu verbinden, was aber nur bei den zwei vorhandenen Verbindungen funktionieren kann. Die Startart ist nur für die zwei Verbindungen auf automatisch gesetzt:
Click to expand...
Wie machst du das Discovery und was spuckt er denn da aus?
larsen said:
Code: 
atl-vm04:# grep -R startup /etc/iscsi/nodes/iqn.1986-03.com.hp:storage.msa2040.15472745cf | grep autom
./10.0.3.140,3260,5/iscsi_enp2s0f0:node.startup = automatic
./10.1.3.150,3260,6/iscsi_enp2s0f1:node.startup = automatic

Alle 3 Minuten und 38 Sekunden kommt solch ein Eintrag:
Code: 
Feb  1 16:07:46 atl-vm04 pvestatd[1524]: command '/usr/bin/iscsiadm --mode node --targetname iqn.1986-03.com.hp:storage.msa2040.15472745cf --login' failed: exit code 15

Vermutlich möchte sich iscsid mit jedem verfügbaren Portal verbinden, was aber natürlich ohne entsprechende Verbindung nicht funktionieren kann (und auch gar nicht benötigt wird).
Wie kann ich dieses Verhalten deaktivieren?

Ich hatte an Löschen der Einträge in "/etc/iscsi/nodes/iqn.1986-03.com.hp:storage.msa2040.15472745cf" gedacht, aber habe bei meiner Recherche gelesen, dass diese ggf. automatisch wiederhergestellt werden.
Click to expand...
Nur bei einem erneuten Discovery. Also eigentlich nur manuell oder beim Reboot.

Eigentlich müsste das auch ganz gut Performance kosten, da er ständig nach Pfaden sucht.
 
larsen said:
Vermutlich möchte sich iscsid mit jedem verfügbaren Portal verbinden, was aber natürlich ohne entsprechende Verbindung nicht funktionieren kann (und auch gar nicht benötigt wird).
Click to expand...
Um das zu prüfen, könntest du bitte die Ausgabe der folgenden beiden Kommandos posten?
Code: 
iscsiadm -m node
iscsiadm -m session
 
Falk R. said:
Wie machst du das Discovery und was spuckt er denn da aus?
Click to expand...
Wurde bei der Einrichtung vor ein paar Monaten so gemacht:

Code: 
iscsiadm -m discovery -t sendtargets -p 10.0.3.140 -I iscsi_enp2s0f0 && \
iscsiadm -m discovery -t sendtargets -p 10.1.3.150 -I iscsi_enp2s0f1

Falk R. said:
Nur bei einem erneuten Discovery. Also eigentlich nur manuell oder beim Reboot.
Click to expand...
D.h. selbst wenn ich das nun manuell lösche und es zunächst funktioniert, wird es immer wieder automatisch neu erstellt werden?
 
fweber said:
Um das zu prüfen, könntest du bitte die Ausgabe der folgenden beiden Kommandos posten?
Click to expand...

Code: 
atl-vm04:~# iscsiadm -m node
10.0.1.100:3260,1 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.1.100:3260,1 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.2.120:3260,3 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.2.120:3260,3 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.3.140:3260,5 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.3.140:3260,5 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.4.160:3260,7 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.0.4.160:3260,7 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.1.110:3260,2 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.1.110:3260,2 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.2.130:3260,4 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.2.130:3260,4 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.3.150:3260,6 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.3.150:3260,6 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.4.170:3260,8 iqn.1986-03.com.hp:storage.msa2040.15472745cf
10.1.4.170:3260,8 iqn.1986-03.com.hp:storage.msa2040.15472745cf
Code: 
atl-vm04:~# iscsiadm -m session
tcp: [1] 10.0.3.140:3260,5 iqn.1986-03.com.hp:storage.msa2040.15472745cf (non-flash)
tcp: [2] 10.1.3.150:3260,6 iqn.1986-03.com.hp:storage.msa2040.15472745cf (non-flash)
 
Habe die nicht benötigten IPs/Verbindungen nun auf einem Host testweise entfernt und seitdem sind bisher keine weiteren Einträge im Log bzgl "no route to host" aufgetaucht. Neustart des Servers wird die Tage noch getestet, wenn es passt.

Code: 
iscsiadm -m node -T ${IQN} -p 10.1.4.170 -I iscsi_enp2s0f0 -o delete
iscsiadm -m node -T ${IQN} -p 10.1.4.170 -I iscsi_enp2s0f1 -o delete
...
 
  • Like
Reactions: Falk R.
Auch nach einem Neustart keine weiteren Einträge mehr. Allerdings wüsste ich zu gerne, warum das auf einmal auftrat, denn nach der Einrichtung des SAN, die erst wenige Monate her ist, kam das noch nicht.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back