iscsi-test-cu – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

iscsi-test-cu – iSCSI/SCSI-Testsuite

ZUSAMMENFASSUNG

iscsi-test-cu [ OPTIONAL ]

iscsi-test-cu [-i --initiator-name= ] [-I --initiator-name-2= ] [-l --list]
[-t --test= |*[. |*[. |*]]] [-d --dataloss]
[-s --allow-sanitize] [-u --usb] [-V --Verbose-scsi] [-x --xml] [-? --Hilfe]

BESCHREIBUNG

iscsi-test-cu ist eine Testsuite für iSCSI/SCSI.

ISCSI PORTAL URL FORMAT

Das iSCSI-Portalformat ist
'iscsi://[ [% ]@] [: ]/ / '

Port ist der TCP-Port auf dem Ziel, zu dem eine Verbindung hergestellt werden soll. Der Standardwert ist 3260.

Benutzername und Kennwort sind nur erforderlich, wenn das Ziel eine CHAP-Authentifizierung erfordert.
Optional können Sie den Benutzernamen und das Passwort über die Umgebungsvariablen angeben
LIBISCSI_CHAP_USERNAME und LIBISCSI_CHAP_PASSWORD.

Host kann entweder als Hostname, IPv4-Adresse oder IPv6-Adresse angegeben werden. Beispiele:

iscsi://192.0.2.1/iqn.ronnie.test/1
iscsi://[2001:DB8::1]:3261/iqn.ronnie.test/1
iscsi://ronnie%[E-Mail geschützt] /iqn.ronnie.test/1

OPTIONAL

-i --initiator-name=
Alle Tests verwenden mindestens eine iSCSI-Verbindung zum Ziel und dies ist der Initiator
Der für diese primäre Sitzung verwendete Name wird standardmäßig verwendet
'iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-test'

Dieses Argument wird verwendet, um zu ändern, welcher Initiatorname für die primäre Sitzung verwendet werden soll.

-I --initiator-name-2=
Einige Tests verwenden eine zweite Verbindung zum Ziel, beispielsweise die „IT-Nexus-Loss-Tests“.
Der für diese zweite Verbindung verwendete Standardname lautet
'iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-test-2'

Dieses Argument wird verwendet, um zu ändern, welcher Initiatorname für die sekundäre Sitzung verwendet werden soll.

-l --list
Dieses Argument listet alle verfügbaren Tests auf.

Die Tests sind in „Familien“, „Suiten“ und „Tests“ unterteilt, getrennt durch „.“.

iscsi-test-cu -l
ALLER
ALL.CompareAndWrite
ALL.CompareAndWrite.Simple
ALL.CompareAndWrite.Miscompare
ALL.GetLBAStatus
ALL.GetLBAStatus.Simple
ALL.GetLBAStatus.BeyondEol
...

-t --test= |*[. |*[. |*]]
Dieses Argument gibt eine durch Kommas getrennte Liste der auszuführenden Testausdrücke an. Wenn dies
Wird das Argument weggelassen, werden alle Tests ausgeführt. Sie können auch einfach a angeben
Dateiname, aus dem die Liste der Tests gelesen werden soll.

So führen Sie alle Tests aus:
iscsi-test-cu --test=ALL iscsi://192.0.2.1/iqn.ronnie/test/1

So führen Sie die READ16-Testsuite aus:
iscsi-test-cu --test=SCSI.Read16.* \
iscsi://192.0.2.1/iqn.ronnie/test/1

Um nur einen einzelnen spezifischen Test auszuführen:
iscsi-test-cu --test=iSCSI.iSCSIResiduals.Read10Invalid \
iscsi://192.0.2.1/iqn.ronnie/test/1

Führen Sie alle Tests in der TestUnitReady-Suite und auch den Reaqd16.Flags-Test aus
iscsi-test-cu --test=SCSI.TestUnitReady.*,SCSI.Read16.Flags \
iscsi://192.0.2.1/iqn.ronnie/test/1

Führen Sie alle in der Datei aufgeführten Tests aus ~/tests-to-run
iscsi-test-cu --test=~/tests-to-run
iscsi://192.0.2.1/iqn.ronnie/test/1

-d --dataloss
Standardmäßig führt das Testtool nur zerstörungsfreie Tests durch. Um die Befehle zu testen
B. bei den Write*-Tests, müssen Sie das Flag --dataloss angeben.

Die Tests, die „--dataloss“ erfordern, überschreiben die Daten auf der LUN und alles andere
Daten auf dieser LUN werden bei der Ausführung dieser Tests zerstört.

-s --allow-sanitize
Es wird erwartet, dass der SBC SANITIZE-Opcode erhebliche Zeit in Anspruch nimmt, bis er abgeschlossen ist
Daher sind Tests für diesen Opcode nicht für normale Testläufe geeignet.

Standardmäßig werden alle SBC SANITIZE-Tests übersprungen. Verwenden Sie diese Argumente, wenn Sie wirklich
Sie möchten SANITIZE-Tests durchführen.

-u --usb
SCSI-Geräte, die sich hinter einem USB-Bus befinden, sind unter Linux auf maximal 120 KB beschränkt
Einzel-SCSI-Lesen*/Schreiben*.

Beim Testen mit einem USB-SCSI-Gerät müssen Sie diese Argumente angeben, damit das
Tests begrenzen die Lese-/Schreibgröße auf maximal 120 KB.

-V --Verbose-scsi
Ziel der Tests ist es, sich selbst zu dokumentieren. Durch Angabe des Flags -V wird das Testtool dies tun
Gibt alle SCSI-Befehle aus, die an das Gerät gesendet werden, die Argumente und die erwarteten
Ergebnis.

Wenn ein Test fehlschlägt, führen Sie den fehlgeschlagenen Test mit dem Argument -V erneut aus, um herauszufinden, warum er fehlgeschlagen ist. Wenn
Das schlägt auch fehl. Es ist an der Zeit, Wireshark herauszuholen und einen Blick darauf zu werfen, was passiert ist.

iscsi-test-cu --test SCSI.Read10.BeyondEol iscsi://192.0.2.1/iqn.ronnie.test/1 -V
Suite: Read10
Test: BeyondEol ...
Testen Sie READ10 1-256 Blöcke einen Block nach dem Ende
Senden Sie READ10 (LBA_OUT_OF_RANGE wird erwartet) LBA:2097152 Blöcke:1 rdprotect:0 dpo:0 fua:0 fua_nv:0 Gruppe:0
[OK] READ10 hat ILLEGAL_REQUEST/LBA_OUT_OF_RANGE zurückgegeben.
...

-x --xml
Diese Option ermöglicht die Erstellung von Testergebnissen in maschinenlesbarem Format für automatisierte Tests.

iscsi-test-cu kann maschinenlesbare Testergebnisse zur Nutzung durch Ihr CI erstellen
Server. Verwenden Sie die Option --xml mit allen Testsuiten und einer Datei namens
CUnitAutomated-Results.xml wird in Ihr aktuelles Arbeitsverzeichnis geschrieben. Diese
Die Ergebnisse können mit diesem Skript in das JUnit-Format konvertiert werden:
http://git.cyrusimap.org/cyrus-imapd/plain/cunit/cunit-to-junit.pl

Der Rückgabestatus des Skripts spiegelt wider, ob die Tests erfolgreich waren oder nicht. Wenn
Sie möchten lieber, dass das Skript einen Status zurückgibt, der angibt, ob die Konvertierung erfolgt ist
von cunit zu junit war erfolgreich. Sie können das Skript folgendermaßen patchen:

diff --git a/cunit-to-junit.pl.orig b/cunit-to-junit.pl
index 7cf9320..9182ff0 100644
--- a/cunit-to-junit.pl.orig
+++ b/cunit-to-junit.pl
@@ -226,4 +226,4 @@ foreach my $s (@suites)
}

print „$0: $nrun-Tests ausgeführt, $nfailed fehlgeschlagen\n“;
-wunsch(1) if ($nfailed > 0);
+#wunsch(1) if ($nfailed > 0);

-? --Hilfe
Grundlegenden Hilfetext anzeigen.

Verwenden Sie iscsi-test-cu online über die Dienste von onworks.net