2008-08-21 11 views
0

Zwei RAID-Volumes, VMware Kernel/Konsole läuft auf einem RAID1, vmdks leben auf einem RAID5. Das Eingeben einer Anmeldung an der Konsole führt nur zu SCSI-Fehlern, keine Kennworteingabeaufforderung. Lob sein, die VMs laufen eigentlich noch. Wir denken jedoch, dass der Kernel nach einem Neustart möglicherweise nicht neu gestartet wird und die VMs nicht verfügbar sind.Mein VMware ESX-Serverkonsolen-Volume wurde schreibgeschützt. Wie kann ich meine VMs speichern?

Wir haben Datenbank- und Festplatten-Backups der VMs, aber keine Backups der vmdks selbst.

Was sind meine Optionen?

Unsere aktuellen beste Idee ist

  1. Verwenden VMware Converter Live vmdks aus der laufenden VMs zu erstellen, als ob es sich um eine P2V-Migration war.
  2. Reboot Host-Server und führen RAID-Diagnose, herauszufinden, was in dem „h“ geschah
  3. Versuch wieder ESX zu starten, möglicherweise nach dem Umbau muß sein RAID-Volume
  4. Möglicherweise neu installieren ESX auf seinem Volumen und Wieder -anmelden VMs
  5. Wenn das nicht funktioniert, hängen Sie die in Schritt 1 erstellten "Live" -VMDKS an einen anderen VM-Host an.

Antwort

1

Es war die Rückwandplatine. Beide Laufwerke des RAID1 und ein Laufwerk des RAID5 waren nicht zugänglich. Unglaublicherweise lief der VMware-Hypervisor drei Tage lang aus dem Speicher, ohne Zugriff auf seine Host-Festplatte zu haben, und hielt die verwalteten VMs am Leben.

In Schritt 3 oben diagnostizierten wir das Hardwareproblem und ersetzten den RAID-Controller, die Kabel und die Rückwandplatine. Nach dem Neustart initialisierten wir das RAID erneut, indem wir den Controller anweisen, die Laufwerke nach ihren Konfigurationen abzufragen. Beide wurden abgebaut und beide wurden erfolgreich repariert.

In Schritt 4 war es nicht notwendig, ESX erneut zu installieren; obwohl er beim Booten die VMs nicht registrieren wollte. Wir mussten etwas vergrabenes Management-Zeug ausgraben, um den Kernel anzuweisen, die VMs zurückzuzahlen. (Suche VM-Dokumente für "resignature.")

Ich glaube, dass unsere Fallback-Plan hätte funktioniert, die VMware Converter Bilder der VMs, die "verwaist" ausgeführt wurden getestet und lief gut ohne Datenverlust. Ich empfehle dringend, eine VMware Converter-Imaging von jeder VM, die in diesen Zustand versetzt wird, durchzuführen, nachdem so viele Dienste wie möglich heruntergefahren wurden und die VM in einen schreibgeschützten Zustand gebracht wurde. Das Laden einer vmdk entweder an anderer Stelle oder auf dem ursprünglichen Host als eine Reparatur wird normalerweise viel schneller sein, als einen Server von Grund auf mit Sicherungen neu aufzubauen.