LinuxIO (LIO)-Ziel @ Debian 10 und VMware 6.7 Initiator: WRITE_PROTECTED LUN-Zugriff für 0x00000000 erkannt

Question

wir rennen

• QNAP NAS
• Debian 10
• Hosten Sie VMware 6.7U3 Hypervisor

a) Das Exportieren eines iSCSI-LUN-Ziels mit dem QNAP, das hierfür LIO verwendet, und der Zugriff darauf von VMware (Lesen/Schreiben) funktioniert einwandfrei.

b) Das Exportieren eines iSCSI-LUN-Ziels mit einem neuen Debian 10 unter Verwendung von LIO und der Zugriff darauf mit einem Windows 7 iSCSI-Initiator (Lesen/Schreiben) funktioniert problemlos.

Die Verwendung des Ziels b) (Debian 10 / LIO) und des Initiators a) (VMware v6.7) funktioniert soweit

• VMware erkennt den Zielhost
• VMware kann sich anmelden und sieht das Ziel
• VMware kann die Daten auf der LUN LESEN (sieht Partitionstabelle, deren Größe, Partitionstypen usw.)

Sobald wir versuchen, etwas zu schreiben, meldet VMware

2020-12-28T14:36:00.775Z info hostd[2098690] [Originator@6876 sub=Partitionsvc opID=esxui-2f96-fbd9 user=root] Status: 255 Ausgabe: gpt 0 0 0 0

Fehler: Fehler: Nur-Lese-Dateisystem während des Schreibens auf /dev/disks/naa.60014054b666e78a1c443ee941c60e3e SetPtableGpt: Übernehmen auf Festplatte nicht möglich

und die Debian 10-Box meldet:

Kernel: [80.210044] TARGET_CORE[iSCSI]: WRITE_PROTECTED LUN-Zugriff für 0x00000000 erkannt

Ich erkenne nicht, warum VMware die iSCSI-LUN schreibgeschützt mountet, Windows 7 sie aber mit Lese-/Schreibzugriff mountet und VMware die QNAP-iSCSI-LUN ebenfalls mit Lese-/Schreibzugriff mountet.

Ich freue mich über jeden Hinweis und bedanke mich schon einmal dafür.

PS: Vielleicht kann jemand das Tag „Linuxio“ erstellen und es dieser Frage zuordnen.

Answer 1

Ich habe tagelang versucht, dieses Problem zu lösen, heute habe ich das Verhalten unter Windows 7 und QNAP-NAS überprüft. Da ich keine Idee mehr hatte, habe ich hier nach ein paar Hinweisen gefragt.

Nach einigen weiteren Stunden des Probierens wurde mir klar, dass der VMware iSCSI-Initiator einen expliziten ACL-Eintrag erfordert, während dies beim Windows 7 iSCSI-Initiator nicht der Fall ist.

Beachten Sie, dass ich das gesamte LIO-System im Demomodus konfiguriert habe, sodass überhaupt keine Authentifizierung erforderlich sein sollte, der Schreibschutz in der Demo deaktiviert war und iqn-ACLs dynamisch generiert werden sollten:

cd /iscsi/iqn.2003-01.org.linux-iscsi.v10000.x8664:sn.cce266f35881/tpg1/

set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1

Ich weiß nicht, warum es so reagiert, aber Windows 7 funktionierte gut ohne einen expliziten ACL-Eintrag und VMware läuft einwandfrei, da ich einen ACL-Eintrag und eine LUN-Zuordnung für den Initiator unter iscsi/iqn..../tpg..../acls/iqn.of-the-initiator hinzugefügt habe.

Danke jedenfalls fürs Lesen, vielleicht spart dieser Beitrag anderen Administratoren Zeit.