[TS-639 als iSCSI Target] LUN ID spezifizieren?

Hallo,

kennt jemand eine Möglichkeit, dem TS-639 (oder TS-509) bei der Konfiguration der iSCSI Targets eine LUN ID ungleich null anzugeben?

Offensichtlich werden alle LUNs mit ID 0 spezifiziert. Bei meinem iSCSI Initiator kann ich das aber nicht gebrauchen, weil wird nur die erste LUN korrekt erkannt. Hier ein Beispiel vom TS-639 mit 2 Test-LUNs

cat /proc/net/iet/volume

liefert:

tid:3 name:iqn.2004-04.com.qnap:TS-639:iSCSI.vm2.BB9470
 lun:0 state:0 iotype:fileio iomode:wb path:/share/MD0_DATA/.@iscsi.img/iSCSI-test2-49806536.000
tid:2 name:iqn.2004-04.com.qnap:TS-639:iSCSI.test2.BB9470
 lun:0 state:0 iotype:fileio iomode:wb path:/share/MD0_DATA/.@iscsi.img/iSCSI-test1-497e0b03.000
tid:1 name:iqn.2004-04.com.qnap:TS-639:iSCSI.test1.BB9470

Ähnliches kennt man u.a. vom "OpenFiler". Dort kann man aber in der /etc/ietd.conf die LUN ID manuell "hinbiegen".

Beim TS-639 liegt die Konfig unter /etc/config/iscsi.conf und scheint mir proprietär zu sein.

Wenn ich das richtig sehe, wird sie vom Skript /etc/init.d/iscsitrgt.sh bzw. "iscsiutil set_param" gelesen und an den ietd übergeben.

Sind die möglichen Parameter der iscsi.conf irgendwo dokumentiert? Habe bislang nichts Brauchbares gefunden. Ein vollständies manuelles Konfigurieren des ietd würde ich gerne vermeiden, weil bräuchte ich dafür kein teures QNAP NAS mit schicker Web-GUI.

Ich bin für jede Idee dankbar.

Akki

Hallo Christian,

ich habe hier 2 VMware ESX Server. Mittlerweile habe ich einen Workaround gefunden und das Ganze für das TS-639 in ein Shell-Script gepackt. Wenn alles wie gewünscht funktioniert, werde ich die Lösung hier im Forum posten. Bin gerade noch beim Testen.

Gruß Akki

So, mein Workaround ist fertig und im Einsatz. Folgendes Script changelunid liegt unter /root/ ab.

#!/bin/sh


IET_PROC=/proc/net/iet/volume
IET_PARAMS=/tmp/iet_params


change_lun_id()
{
  while read -r TID NAME; do
    if [ ! -e $TID ]; then
      read LUN STATE IOTYPE IOMODE PATH
      nLUN=`echo $LUN | /bin/sed s/[a-z]*://`


      if [ $nLUN -eq 0 ]; then
        nTID=`echo $TID    | /bin/sed s/[a-z]*://`
        nNAME=`echo $NAME   | /bin/sed s/[a-z]*://`
        nSTATE=`echo $STATE  | /bin/sed s/[a-z]*://`
        nIOTYPE=`echo $IOTYPE | /bin/sed s/[a-z]*://`
        nIOMODE=`echo $IOMODE | /bin/sed s/[a-z]*://`
        nPATH=`echo $PATH   | /bin/sed s/[a-z]*://`


        oLUN=$nLUN
        nLUN=$nTID


        /bin/cat >>$IET_PARAMS<<EOF
/sbin/ietadm --op delete --tid $nTID --lun $oLUN
/sbin/ietadm --op new --tid $nTID --lun $nLUN --params Path=$nPATH,Type=$nIOTYPE,IOMode=$nIOMODE
EOF
      fi
    fi
  done
}


echo "#!/bin/sh" > $IET_PARAMS
change_lun_id < $IET_PROC
/bin/sh $IET_PARAMS

Erläuterung

Es werden zunächst die aktuellen iSCSI Target Einstellungen aus /proc/net/iet/volume gelesen und umgebaut.

Um die LUN IDs eindeutig und ungleich null zu bekommen, setze ich sie als Workaround einfach mit der Target ID gleich. Anschließend wird ein Script /tmp/iet_params generiert, das bei seiner Ausführung mittels "ietadm" die bisherigen Targets neu baut, jedoch mit veränderten LUN IDs. Bereits abgeänderte Targets mit LUN ID ungleich null bleiben unverändert. Anschließend wird iet_params ausgeführt.

Wer ein wenig googelt, findet in der Mail eines QNAP Technikers den Hinweis, das QNAP wohl auch ietadm verwendet, um die Targets zu bauen. Daher findet sich auch nirgends eine ietd.conf im System (Ich habe zumindest keine auf meinem TS-639 ausfindig machen können). Hinderlich ist ein wenig, dass bei Änderungen an der iSCSI Konfiguration mittels Web-GUI ein GCI-Script aufgerufen wird, das wohl ebenso ietadm startet, um die Änderungen am Target vorzunehmen.

Das hat bei mir dann den Effekt, dass die betroffene LUN wieder mit ID 0 auftaucht. Also muss ich obiges Script kontinuierlich ausführen. Ab damit in die crontab und jede Minute kurz ausführen.

Ergebins

Habe den Mechanismus nun ein paar Stunden laufen und wie wild iSCSI Targets erzeugt und gelöscht, mit ESX nach den Volumes gescannt, VMs von einem Target in ein anderes migriert und bislang keine Probleme festgestellt. Damit kann ich zunächst mal leben. Nicht wirklich cool aber effektiv.

Für das nächste Firmware-Update wünsche ich mir dann doch bitte ein wenig mehr Einflussmöglichkeiten in die iSCSI Konfiguration des TS-639. Im direkten Vergleich zum Thecus NAS finde ich die iSCSI Konfiguraton unter QNAP doch deutlich "wilder", weil alles schön verborgen. Eigentlich schade!

Gruß Akki

PS: Für eventuelle Schäden am System, Verlust von Volumes oder Verlust von Daten wird keine Haftung übernommen. Wer Fehler im Script findet, möge bitte eine PN senden. Vielen lieben Dank.

Hallo,

in der aktuellen Implementierung erwartet VMware ESX, dass eine LUN eindeutig adressiert werden kann und eine eindeutige ID hat. Das Schema ist hierbei

vmhbaA:T:L:P

wobei

A: Adapter
T: Target
L: LUN
P: Partition.

Das TS-639 publiziert mit der derzeitigen Firmware seine LUNs zwar mit unterschiedlichen Target IDs, jedoch alle mit LUN ID 0 .

Aus Sicht ESX bedeutet das: Der Host sieht verschiedene LUNs des TS-639 als eine identische LUN, die über mehrere Targets IDs adressiert wird. Die Erwartung ist aber, verschiedene LUNs auf demselben (physischen) Target adressieren zu können. Die Lösung besteht darin, die LUN IDs eindeutig zu machen.

Ob sich andere (Linux/Unix basierten) iSCSI Initiator Implementierungen anders verhalten, kann ich ad hoc nicht sagen. Beim ESX ist es zumindest so implementiert. Die Erfordernis der Eindeutigkeit scheint hierbei wohl im Zusammenhang mit LUN Multipathing und LUN Discovery zu stehen.

Soll nur eine iSCSI LUN über das TS-639 bereitgestellt werden, ist das Ganze unproblematisch. Soll ESX auf eine iSCSI LUN zugreifen und ein Windows System auf eine andere iSCSI LUN, könnte man die ESX LUN als erste auf dem NAS erzeugen. Im MS iSCSI Initiator kann die zweite LUN dann problemlos ausgewählt werden.

Sollen aber mehrere iSCSI LUNs für ESX zum Einsatz kommen, würde ich schon raten, sich über die Eindeutigkeit der LUN IDs Gedanken zu machen.

Gruß Akki