Windows Server 2012 kann nicht von iSCSI gestartet werden

Ich arbeite daran, wie verschiedene Betriebssysteme auf plattenlosen Servern installiert werden, die über iSCSI ausgeführt werden sollen. Die Server haben hierfür keine spezielle Hardware (keine iSCSI-HBAs etc.)

Ich habe kurz mit Windows-Bereitstellungsdiensten gespielt, aber es scheint ungefähr das Gegenteil von dem zu sein, was ich möchte: Ich könnte mich irren, aber es scheint darauf ausgelegt zu sein, eine netzwerkbasierte Installation von Windows auf einem System durchzuführen, das dann von einer lokalen Festplatte gestartet wird Ich möchte Windows so installieren, dass es von einer iSCSI-Festplatte ausgeführt wird, und es ist mir egal, ob Installationsmedien lokal eingelegt werden müssen. Daher verwendet mein gegenwärtiger Ansatz kein WDS.

Dieser Test wurde von Windows Server 2012 durchgeführt, gilt jedoch wahrscheinlich auch für frühere Versionen.

Kurz gesagt, ich richte ein leeres iSCSI-Ziel ein (ich habe mehrere S / W-Anbieter ausprobiert und es scheint keinen großen Unterschied zu machen, obwohl ich derzeit StarWind verwende) und verwende PXE, um es mit gPXE oder iPXE zu verketten ein iSCSI-Boot (Ich habe beide ausprobiert, mit ähnlichem Ergebnis, obwohl ich fand, dass gPXE etwas einfacher zu verwenden ist.)

Ohne Betriebssystem schlägt der Start natürlich fehl, aber die LU bleibt über die BIOS-Festplattenschnittstelle angeschlossen, sodass das Installationsprogramm beim Booten der lokalen DVD-ROM das Volume sieht, auf dem installiert werden soll.

Ich führe den Startvorgang durch, indem ich zu einer gPXE-Eingabeaufforderung gehe und die folgenden Befehle eingebe (dasselbe in iPXE mit Ausnahme der Schnittstellennummer):

dhcp net1
set keep-san 1
sanboot iscsi:#.#.#.#::::iqn.xxxxxxxxxxxxxxxxxxx
exit

Windows Server 2012 scheint zu installieren und irgendwann neu zu starten. iPXE startet, um von iSCSI zu booten, und das 'Metro'-Logo wird angezeigt - so wurde zumindest etwas auf der LU installiert. Der Bildschirm wird dann jedoch hellblau und eine Meldung blinkt kurz in großem Text. Etwas über den "PC" (es ist eigentlich ein Rack-Server, aber trotzdem) stößt auf ein Problem, aber ich kann nicht alles lesen, bevor es verschwindet und der Computer es ist Neustart.

Schließlich erhalte ich einen Textbildschirm mit Windows Boot Managerdem Titel :

Windows failed to start. A recent hardware or software change might be the
cause. To fix the problem:

  1. Insert your Windows installation disc and restart your computer.
  2. Choose your language settings, and then click "Next."
  3. Click "Repair your computer."

If you do not have this disc, contact your system administrator or computer
manufacturer for assistance.

    File: \Windows\system32\ntoskrnl.exe

    Status: 0xc00000e9

    Info: The operating system couldn't be loaded because the kernel is
          missing or contains errors

Diejenigen, die genau hinschauen, werden feststellen, dass es sehr schwierig ist, diese Anweisungen effektiv zu befolgen, insbesondere bei physischer Hardware. (Übrigens habe ich versucht, Installationen sowohl auf physischen als auch auf virtuellen Maschinen mit ähnlichen Ergebnissen durchzuführen.)

Ich vermute, was hier passiert, ist, dass Windows 2012 so weit kommt, weil iPXE Interrupt 13h (BIOS-Festplattendienste) angeschlossen hat, aber sobald das System weit genug gebootet hat, um auf Treiber im geschützten Modus umzuschalten, wird der Start grob unterbrochen, weil Es gibt keine Festplatte zum Lesen und / oder der iSCSI-Initiator von Windows schlägt fehl.

Das iPXE, das ich versuche, ist 1.0.0+ (3fcb) und das gPXE, das ich ausprobiert habe, war 1.0.1.

Ist es möglich, dass Server 2012 iSCSI ohne Hardware-HBA ausführt, und wenn ja, was kann ich falsch machen?

(Meine erste Antwort war verfrüht. Wie versprochen habe ich sie umgeschrieben, nachdem alles funktioniert hat.)

Zunächst habe ich festgestellt, dass die iSCSI-Boot-fähige Software im Allgemeinen nur halbherzig ist und die beteiligten unterschiedlichen Systeme nur sehr schlecht zusammenarbeiten. Aus diesem Grund empfehle ich, wenn möglich stattdessen eine hardwarebasierte Lösung wie iSCSI-HBAs zu verwenden. Vor diesem Hintergrund werde ich meine Erfahrungen hier erzählen, falls es jemandem hilft.

Um zusammenzufassen, was ich gefunden habe (ich gehe davon aus, dass Sie DHCP und TFTP für PXE und ein iSCSI-Ziel eingerichtet und die Verkettung mit gPXE oder iPXE erreicht haben):

• gPXE und iPXE schreiben niemals mehrere Netzwerkkarten in die iBFT (iSCSI Boot Firmware Table). Dies kann sich auf Windows Server auswirken. Ich habe dieses Problem hier in einer separaten Frage ausführlich erörtert .

• Zusätzlich zu der oben genannten Designbeschränkung weist gPXE einen tatsächlichen Fehler auf, der ebenfalls Systeme mit mehreren Netzwerkports betrifft. Ich werde unten erklären. Um diesen Fehler zu vermeiden, habe ich den Build "UNDI only" von gPXE verwendet. Dies verhindert, dass gPXE direkt auf die Netzwerkkarten zugreift, und verwendet stattdessen eine API, die vom PXE-Loader der Netzwerkkarte bereitgestellt wird. Dies lässt gPXE denken, dass es nur einen Netzwerkport gibt (den, auf den es geladen wurde), und dies umgeht den Fehler. Ich bin nicht sicher, ob dieser Fehler in neueren iPXE-Versionen vorhanden ist.

• Ich war anfangs verwirrt über die keep-sanOption in gPXE / iPXE. Das keep-sanFlag wirkt sich nur dann auf das Verhalten von gPXE aus, wenn der Start fehlschlägt . Daher wird diese Option nur beim ersten Start beim Start der Installation benötigt.

• Windows Server (mindestens 2012 und wahrscheinlich auch andere) toleriert offenbar nicht das Verschieben des iSCSI-Initiators, der seine Systemfestplatte bereitstellt, von einem Netzwerkport auf einen anderen. Wenn Windows von einem Initiator an einem anderen Netzwerkport als dem, auf dem es installiert wurde, gestartet wird, stürzt Windows beim Start beim Übergeben an den MS-Initiator ab (BSOD und / oder Neustart).

• In Windows Server (2003 und höher) gibt es eine anerkannte Funktion / ein anerkanntes Problem, bei dem das Gateway (sofern angegeben) für den Zugriff auf das Ziel verwendet wird, selbst wenn sich das Ziel im lokalen Subnetz befindet. Wenn das Gateway nicht verfügbar ist oder nicht auf denselben Port zurückgeleitet wird, schlägt der Start bei der Übergabe an den MS-Initiator fehl. Stellen Sie sicher, dass vom DHCP keine Gateway-Einstellung ausgegeben wird, falls keine benötigt wird.

Der oben erwähnte gPXE-Fehler betrifft die iBFT (iSCSI Boot Firmware Table). Dies ist ein Objekt, das vom Pre-Boot-System in den Speicher gestellt wird und Informationen zu den Netzwerkkarten, dem iSCSI-Initiator und dem iSCSI-Ziel enthält, das als Systemfestplatte verwendet werden soll. Das Betriebssystem verwendet diese Informationen, um den Startvorgang fortzusetzen, sobald es in den geschützten Modus wechselt. Das Format wird hier angegeben .

Ich vermutete ein Problem mit den Informationen, die gPXE in der iBFT platzierte, und programmierte einen Bootsektor, der den Inhalt der iBFT auf dem Bildschirm ausgibt. Dabei stellte ich fest, dass die von gPXE geschriebenen Daten unter bestimmten Umständen fehlerhaft sind.

Wie bereits erwähnt, schreibt gPXE nur einen NIC-Datensatz in die iBFT. In einigen Situationen werden jedoch die in diesen einen NIC-Datensatz geschriebenen Informationen durcheinander gebracht. Die MAC-Adresse und die PCI-Adresse entsprechen einer Netzwerkkarte, die lokalen IP- und Gateway-Adressen entsprechen jedoch einer anderen. Dies ist am wahrscheinlichsten, wenn sich das SAN nicht auf der ersten Netzwerkkarte befindet.

Um die Verwirrung zu vergrößern, werden diese falschen iBFT-Informationen geschrieben, wenn gPXE automatisch gestartet wird. Beim Booten über die Eingabeaufforderung von gPXE werden jedoch abhängig von der genauen Reihenfolge der eingegebenen Befehle möglicherweise die richtigen Informationen geschrieben. Wenn Sie die Tatsache berücksichtigen, dass Windows Symptome aufweist, die mit denen identisch sind, die durch diesen Fehler verursacht wurden, wenn die Netzwerkkarte geändert wurde (selbst wenn eine korrekte iBFT angegeben wurde), können Sie sehen, warum ich mir die Haare herausgerissen habe.

Übrigens hatte ich in meiner ursprünglichen Frage gedacht, dass es für Server 2008 R2 funktioniert, aber nicht für Server 2012. (Ich bearbeite das, da es irreführend ist.) Ich vermute, dass es tatsächlich keinen Unterschied in ihrem zugrunde liegenden Verhalten gibt und dass das anders ist Ergebnisse aufgrund der Feinheiten der oben genannten Probleme und geringfügiger Abweichungen in meinen Tests.