Die ESXi-Verwaltung schlägt fehl und verweigert Verbindungen, nachdem das Startlaufwerk aus einem Backup kopiert wurde

Question

Ich schreibe dies, nachdem ich die Lösung selbst gefunden habe, denn es war ein so seltsames „Problem“, dass es eine Dokumentation verdient.

Obwohl ich bei einer Wiederherstellung auf dieses Problem gestoßen bin, ist es möglich, dass es auch in anderen Fällen beim Booten in ein anderes Betriebssystem auftritt, während das Boot-Laufwerk einer ESXi-Installation an das System angeschlossen ist, insbesondere wenn sich die Festplattengröße geändert hat.

Ich habe erst kürzlich das Startlaufwerk einer VMware ESXi-Installation wiederhergestellt, das auch einen Datenspeicher mit den meisten VMs und ihren virtuellen Start-/Systemfestplatten enthielt, nur um festzustellen, dass dieser vermeintlich einwandfreie Zustand irgendwie durcheinander geraten war.

Basierend auf der Anzeige auf der lokalen Konsole des Servers schien ESXi normal zu booten, zeigte jedoch viele problematische Symptome:

• Ich konnte mich nicht mit dem vSphere-Client anmelden, der die Meldung „vSphere-Client konnte keine Verbindung herstellen zuGastgeber. Ein unbekannter Verbindungsfehler ist aufgetreten. (Die Anforderung ist aufgrund eines Verbindungsfehlers fehlgeschlagen. (Verbindung zum Remote-Server nicht möglich))“.

• Das Protokoll des vSphere-Clients enthielt einen Fehler:

  System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

• Beim Versuch, sich mit einem Webbrowser beim Server anzumelden, meldete der Browser, dass die Verbindung abgelehnt wurde.

• Auch nach Aktivierung auf der lokalen Konsole war keine SSH-Anmeldung zum Server möglich.

• Ein Neustart des Verwaltungsnetzwerks und der Verwaltungsagenten über die lokale Konsole hat das Problem nicht behoben.

• Auf der lokalen Konsole hostdlief „discovery“ nicht und ein Neustart hat das Problem nicht behoben.

• esxcliBefehle gaben immer:Connect to localhost failed: Connection failure

• Es waren weniger Verzeichnisse vorhanden /vmfs/volumesals erwartet und keines davon schien zu meinen Datenspeichern zu gehören.

• Sogar „Systemkonfiguration zurücksetzen“ in der lokalen Benutzeroberfläche hat das Problem nicht behoben. (Ich habe das nur versucht, weil ich ein zweifelsohne funktionierendes Image hatte, von dem ich die Wiederherstellung durchführen konnte. Das habe ich getan, nachdem das Problem gelöst war, obwohl ich nicht sicher bin, ob es überhaupt etwas geändert hat.)

Die Sicherungskopie, von der ich die Wiederherstellung vornahm, war ein Low-Level-Image der logischen RAID-Festplatte, das bei ausgefallenem Server erstellt wurde. Nachdem ich ein möglicherweise beschädigtes RAID-Array gelöscht und neu erstellt hatte, verwendete ich ein separates Laufwerk, das an einen HBA angeschlossen war, um eine physische Windows Server-Installation zu starten und das Image auf das neue RAID zu kopieren. Ich verwendete das HDD Raw Copy Tool vonhddguru.com, was im Grunde eine weniger kryptische und nervenaufreibende Alternative zum Linux- ddBefehl ist.

(Das ist zugegebenermaßen eine barbarische – wenn auch ziemlich umfassende – Methode, VMware zu sichern, aber auf dieser Platte werden hauptsächlich nur VM-Boot-/Systemplatten und keine Daten gespeichert, daher wird sie ohnehin nicht sehr häufig gesichert, außer bei größeren Änderungen. Für Primärdaten haben wir viel bessere Sicherungssysteme.)

Ich habe die neue logische RAID-Festplatte größer gemacht als die, die gesichert wurde, da wir auf größere Laufwerke im RAID aufgerüstet haben und der Datenspeicher etwas voll war. Ich hatte geplant, den Datenspeicher zu vergrößern, nachdem ich bestätigt hatte, dass das Backup funktionierte.

Kaum hatte ich die Rohkopie fertig, bootete ich ESXi und stellte fest, dass es kaputt war. Was ist passiert?!

Dies ist ein ziemlich alter ESXi 5.0 U3. (Er erfüllt unsere aktuellen Anforderungen gut und wir haben kein Vollzeit-IT-Personal, das Upgrades nur um der Upgrades willen verwaltet, die Probleme behebt, die sie häufig verursachen usw.)

Answer 1

In meinem Fall könnte der Schaden von Windows herrühren, aber auch andere Software könnte das gleiche Problem verursachen.

Dies gilt definitiv für ESXi 5.0 U3 und wahrscheinlich für alle ESXi 5.x und ich vermute, möglicherweise auch für alle ESXi 6.x. Es gilt weniger wahrscheinlich für ESXi 7, das ein anderes, einfacheres Partitionslayout verwendet.

Untersuchungshintergrund

Ich war kurz davor, eine Neuinstallation durchzuführen, als ich endlich dahinterkam.

Als ich darin herumstöberte /vmfs/volumes, fiel mir etwas Merkwürdiges auf: $RECYCLE.BINIn allen Verzeichnissen befanden sich Dateien DESKTOP.INI, deren Inhalt mit den Shell-Erweiterungen des Windows Explorers übereinstimmte. Das ist etwas eigenartig, wenn man das in den Systempartitionen eines Hypervisors findet, der nicht auf Windows basiert und nie darauf basiert hat.

Ich hatte sofort den Verdacht, dass das Windows-Betriebssystem, das ich zum Kopieren des Disk-Images verwendet hatte, etwas damit gemacht hatte. ESXi verwendet mehrere FAT-Partitionen auf seiner Startdiskette, also könnte Windows vielleicht mit ihnen herumspielen. Wenn man bedenkt, dass das Disk-Image ansonsten aus einem bekanntermaßen einwandfreien Zustand erstellt wurde, aber fehlschlug, ohne überhaupt etwas zu tuninnerhalbESXi, dies schien die vielversprechendste Untersuchungsrichtung zu sein.

Ich war zunächst bestürzt, als ich mit einem Hex-Editor feststellte, dass diese $RECYCLE.BINVerzeichnisse auch im Disk-Image auftauchten. Zunächst nahm ich an, dass der Schaden bereits vor der Erstellung des Images entstanden war – auch in Windows Server. Diese Einträge erwiesen sich jedoch als harmlos, führten mich jedoch in die richtige Richtung. Windows fügte diese wahrscheinlich hinzu, sobald es die ursprüngliche logische Festplatte sah, die noch nicht vergrößert worden war – und obwohl die Festplatte die ganze Zeit „offline“ gehalten wurde.

Weiteres Herumstöbern im Hex-Editor (HxD - Hex-Editor und Disk-Editor, wirklich gutes Tool) hat einen merkwürdigen kleinen Unterschied zwischen der GPT-Partitionstabelle im Disk-Image und der auf der neuen RAID-Festplatte offenbart. Dies ist kein Unterschied, den ein Partitionseditor angezeigt hätte, dennes macht eigentlich keinen logischen Unterschied, soweit ich weiß. Um das zu finden, müsste man schon in einem rohen Hex-Dump herumstochern.

Grundursache

In beiden Fällen gab es sieben nicht leere Einträge im Partitions-Array. Allerdings gab es, so wie ESXi das Array ursprünglich geschrieben hatte, nach den ersten drei Einträgen eine Lücke von einem leeren Eintrag (alle 128 Bytes auf Null gesetzt), sodass die letzten vier gültigen Einträge in ihren eigenen 512-Byte-Sektor fielen. Auf der Live-Festplatte, auf der ESXi kaputtgegangen war, wurden die letzten vier gültigen Einträge um einen Eintrag nach oben verschoben, um die Lücke zu schließen. Die Einträge waren ansonsten identisch.

Ich weiß nicht, wer das gemacht hat, Windows oder HDD Raw Copy Tool, aber ich vermute, dass es Windows war. Ich habe es noch einmal getestet und diese Änderung wird vorhanden seinsofortnachdem der Kopiervorgang abgeschlossen ist, selbst wenn das logische RAID-Laufwerk während und nach dem Kopiervorgang im MMC-Snap-In „Datenträgerverwaltung“ „Offline“ ist. Dies ist offensichtlich eine beabsichtigte Änderung, da die CRCs alle korrekt sind und die Sicherungs-GPT ebenfalls geändert wird.

Meine Theorie ist, dass derjenige, der dies tut, die GPT neu schreibt, weil sie nicht mit der Größe der Festplatte übereinstimmt, und dass er, anstatt einfach das vorhandene Array exakt zu kopieren, die Partitionen als Liste in einer internen Struktur speichert und dann das Array direkt neu schreibt, wodurch natürlich keine Lücke entsteht.

Als Randbemerkung sei erwähnt, dass die Einträge im Array, wie sie von ESXi geschrieben wurden, nicht in derselben Reihenfolge waren, in der die Partitionen physisch auf der Festplatte vorkommen, aber welches Programm auch immer die Lücke geschlossen hat, es hat sich zum Glück nicht die Freiheit genommen, die Einträge auch zu sortieren!

Manuelle Korrektur

Ich kenne keine einfache Möglichkeit, diese Lücke nachzubilden, da jeder Partitionseditor im Allgemeinen dasselbe tun wird: die vorhandene Tabelle in eine interne Darstellung konvertieren, die vom Tool verwendet wird, die gewünschten Änderungen an dieser Darstellung vornehmen und die Tabelle dann im GPT-Format zurückschreiben, sodass sie die richtigen Daten enthält. Die genaue Positionierung der Array-Einträge auf der Festplatte ist meines Wissens nicht relevant und daher nicht Teil der „richtigen Daten“, die zurückgeschrieben werden.

Ich hatte jedoch das Gefühl, dass ESXi beim genauen Array-Layout pingelig sein könnte, also beschloss ich, es manuell zu korrigieren, um zu sehen, was passieren würde. Das Verfahren war:

1. Stellen Sie vorsichtshalber sicher, dass der Datenträger im MMC-Snap-In „Datenträgerverwaltung“ „Offline“ ist.
2. Öffnen Sie die Diskette in einem Hex-Editor. In HxD befindet sie sich unterExtras→Datenträger öffnen...und Sie müssen es unter „Physische Datenträger“ auswählen. Achten Sie darauf, „Nur lesend öffnen“ zu deaktivieren, was standardmäßig aktiviert ist. Sie erhalten eine entsprechende Warnung, dass dies gefährlich ist.
3. Schieben Sie im Array des primären GPT, das normalerweise bei LBA 2 beginnt (bestätigen Sie das Quadword des Headers bei 48h), die Einträge nach unten, die nach der Lücke stehen sollen, indem Sie Bereiche kopieren, weiter unten einfügen und dann die Lücke auf Null setzen. Besser noch, kopieren Sie einfach die eigentliche Tabelle aus dem Backup-Image, falls Sie eines haben. Beachten Sie jedoch, dass Sie, wenn sich die Größe der LUN geändert hat, nicht einfach den GPT-Header kopieren können, da sich die Situation sonst wiederholen könnte, da dieser Header die falschen Werte für die Felder 20h und 30h enthält.
4. Wähle ausgesamteBereich des GPT-Arrays. Technisch gesehen müssen Sie den Bereich mithilfe des Produkts der Doppelwörter bei 50h und 54h im GPT-Header bestimmen, aber diese Zahl beträgt normalerweise 16.384 Bytes.
5. Nehmen Sie den CRC32 des in Schritt 4 ausgewählten Bereichs. Ich konnte die mathematischen Parameter für den CRC32-Algorithmus in der UEFI-Spezifikation nicht finden, konnte aber herausfinden, dass es sich um einen sehr gebräuchlichen Algorithmus handelt, nämlich den in ISO 802-3, mit dem normalen Polynom 04C11DB7h. Sie können ihn mit einem Online-Rechner berechnenHier, und stellen Sie sicher, dass „Eingabetyp“ auf Hex gesetzt ist. Fügen Sie dies im Little-Endian-Format bei 58h in den GPT-Header ein.
6. Platzieren Sie vorübergehend Nullen in den vier Bytes des GPT-Headers bei 10 Uhr.
7. Nimm den CRC32 des Headers, dessen Länge im Header selbst durch das Doppelwort bei 0Ch angegeben ist. Platziere diesen im Header bei 10h.
8. Wiederholen Sie die Schritte 3 bis 7 für das Backup-GPT. Das Array und sein CRC sind gleich, Sie können diese also einfach kopieren, aber der Header ist anders und hat daher einen anderen CRC. Der Header für das Backup befindet sich normalerweise im allerletzten Sektor der Festplatte, mit dem Array direkt davor, aber technisch gesehen sollten Sie zur Bestätigung das Quadword 20h im primären GPT-Header und das Quadword 48h im Backup-Header überprüfen.
9. Wenn du bistkomplett sicherWenn Sie alles richtig gemacht haben, klicken Sie auf Speichern. Auch hier gibt Ihnen HxD eine entsprechende Warnmeldung.

Sie können dieWikipedia-Artikelfür die grundlegenden technischen Details des GPT-Formats.

Screenshots

So sah ein Teil des „defekten“ GPT-Arrays aus. Beachten Sie, dass die gültigen Einträge bei 77Fh enden und dass davor keine langen Folgen von Nullen vorhanden sind:

So habe ich das Problem behoben. Beachten Sie, dass die gültigen Einträge jetzt bei 7FFh enden:

Ergebnis

Ich habe nicht wirklich erwartet, dass das funktioniert. Ich habe es nicht studiert, würde aber erwarten, dass die UEFI-Spezifikation der Reihenfolge oder dem Abstand von Array-Einträgen keine Bedeutung beimisst. Tatsächlich hat jede Partition eine eindeutige GUIDgenaudamit Sienichtmüssen sich auf solche instabilen Heuristiken verlassen. Daher wäre es keine gute Idee, sich darauf zu verlassen, dass die Array-Indizes dieselben sind wie beim Schreiben der Tabelle.

^{(Andererseits wäre es nicht das erste Mal, dass ich sehe, wie sich Software und Firmware auf Unternehmensebene schlechte Ideen zu eigen machen. Es scheint, als würde ich bei jeder Gelegenheit, bei der ich meinen Sysadmin-Hut aufsetze, mit dem einen oder anderen unglaublich dummen Programmteil konfrontiert ... aber ich will nicht schimpfen.)}

Also habe ich die optimierte Tabelle vorsichtig gespeichert, das RAID neu gestartet, ESXi gestartet, den vSphere-Client verbunden und alles war wieder normal.

Im Idealfall ist es besser, etwas wie Veeam Backup zu verwenden, aber in manchen Situationen mehrad hocMöglicherweise sind Lösungen angebracht. In diesem Fall kann es zu diesem Fehler kommen.