Ich habe 2 RHEL 7.1 VMWare-VMs (Server und Client), die mit einem privaten VMware-Netzwerk verbunden sind. Sie verfügen jeweils über 2xe1000-NICs mit Teaming.
Ich sehe, dass die Teamarbeit wie erwartet funktioniert.
Ich habe auch iscsi auf der Server-VM konfiguriert, das ein Ziel bereitstellt, das wiederum per UUID in der fstab auf dem Client-Computer auf meiner Client-VM gemountet ist.
Auf dem Client-Rechner
[root@client ~]# iscsiadm -m discovery -t st -p server
192.168.100.11:3260,1 iqn.2012-06.com.example:server20gb
[root@client ~]# iscsiadm -m Sitzung -P3
iSCSI-Transportklasse Version 2.0-870
Version 6.2.0.873-28
Ziel: iqn.2012-06.com.example:server20gb (nicht Flash)
Aktuelles Portal: 192.168.100.11:3260,1
Persistentes Portal: 192.168.100.11:3260,1
**********
Schnittstelle:
**********
Iface-Name: Standard
Iface-Transport: tcp
Iface-Initiatorname: iqn.1994-05.com.redhat:c1fef4191c2e
Iface IP-Adresse: 192.168.100.10
Iface HW-Adresse:
Iface Netdev:
SID: 1
iSCSI-Verbindungsstatus: ANGEMELDET
iSCSI-Sitzungsstatus: LOGGED_IN
Interner iscsid-Sitzungsstatus: KEINE ÄNDERUNG
*********
Zeitüberschreitungen:
*********
Wiederherstellungs-Timeout: 120
Timeout für Ziel-Reset: 30
Zeitüberschreitung beim LUN-Reset: 30
Abbruch-Timeout: 15
*****
KERL:
*****
Nutzername:
Passwort: ********
Benutzername_in:
Passwort_eingeben: ********
************************
Ausgehandelte iSCSI-Parameter:
************************
HeaderDigest: Keine
DataDigest: Keine
MaxRecvDataSegmentLength: 262144
MaxXmitDataSegmentLength: 262144
Länge des ersten Bursts: 65536
MaxBurstLength: 262144
ImmediateData: Ja
InitialR2T: Ja
MaxOutstandingR2T: 1
************************
Angeschlossene SCSI-Geräte:
************************
Hostnummer: 33 Status: läuft
scsi33 Kanal 00 ID 0 Lun: 0
Angeschlossene SCSI-Festplatte SDC Status: läuft
Ich kann die Festplatte problemlos per UUID mounten.
[root@client ~]# blkid /dev/sdc1
/dev/sdc1: UUID="de892bb0-7da8-4373-b169-9c465caf2699" TYPE="ext4"
Das Problem, das ich habe, ist, dass beim Neustart das iscsi-Ziel nicht gemountet werden kann. Wenn ich in den Wartungsmodus gehe und nachschaue, scheint es, als gäbe es kein Netzwerk, weshalb der iscsid-Daemon mit
[root@client ~]# journalctl -u iscsid -- Protokolle beginnen am Sonntag, 04.10.2015, 18:19:10 Uhr (BST) und enden am Sonntag, 04.10.2015, 18:32:31 Uhr (BST). -- 04. Okt 18:19:15 client.maclab systemd[1]: Open-iSCSI wird gestartet... Okt 04 18:19:15 client.maclab systemd[1]: PID konnte nicht aus Datei /var/run/iscsid.pid gelesen werden: Ungültiges Argument 04. Okt 18:19:16 client.maclab iscsid[1617]: iSCSI-Daemon mit pid=1618 gestartet! 04. Okt 18:19:16 client.maclab systemd[1]: Open-iSCSI gestartet. 04. Okt. 18:19:17 client.maclab iscsid[1617]: kann keine Verbindung zu 192.168.100.11:3260 (-1,101) herstellen 04. Okt. 18:19:20 client.maclab iscsid[1617]: Session1-Priorität konnte nicht festgelegt werden. LESEN/SCHREIBEN durchgehend und Latenz könnte beeinträchtigt sein. Okt 04 18:19:20 client.maclab iscsid[1617]: Connection1:0 zu [target: iqn.2012-06.com.example:server20gb, portal: 192.168.100.11,3260] über [iface: default] ist jetzt betriebsbereit 04. Okt 18:32:31 client.maclab systemd[1]: Open-iSCSI gestartet.
Mache ich hier etwas Dummes? Warum sollte iscsid vor dem Netzwerkstart starten? Übersehe ich beim Booten ein Kernelmodul?
Danke!
Jim
Antwort1
Es scheint, als ob es sich um einen Fehler in meiner fstab handelte, ich musste die Option übergeben _netdev.
Mein fstab-Eintrag sieht jetzt so aus
UUID=de892bb0-7da8-4373-b169-9c465caf2699 /iscsi ext4 _netdev,rw 0 0
Jetzt scheint der Start problemlos zu funktionieren.