VM startet nicht? Aktiviere die Startdiagnose

Eine CloudTrips-VM beendet den Startvorgang nicht. Azure Boot diagnostics erfasst ein Hypervisor-Konsolenbild und die Ausgabe der seriellen Konsole, selbst wenn SSH, das Netzwerk oder der Azure VM Agent nicht verfügbar sind.

Die Startdiagnose hilft, den Fehler zu erkennen; sie repariert die VM nicht. Die serielle Linux-Ausgabe kann beispielsweise einen fehlerhaften /etc/fstab-Eintrag, ein volles Root-Dateisystem, Dateisystemfehler, Kernel-Fehler oder eine Notfall-Shell sichtbar machen.

Verwende die vorhandene Linux-VM

Verwende die Standard-Ubuntu-VM aus dem Linux-VM-Trip:

Resource group: rg-cloudtrips-compute-test-weu
Virtual machine: vm-cloudtrips-linux01-test-weu

Die VM kann ausgeführt oder beendet sein. Zum Aktivieren und Anzeigen der Startdiagnose benötigst du keinen SSH-Zugriff.

Aktiviere die verwaltete Startdiagnose

Öffne die VM im Portal. Wähle unter Help die Option Boot diagnostics und öffne anschließend Settings.

Wähle:

Boot diagnostics: Enable with managed storage account (recommended)

Wähle Save. Falls diese Option bereits ausgewählt ist, wurde die Startdiagnose bei der VM-Erstellung aktiviert und es ist keine Änderung nötig.

Bei der verwalteten Startdiagnose musst du kein eigenes Speicherkonto erstellen. Azure verwaltet den Diagnosespeicher; für das gespeicherte Konsolenbild und serielle Protokoll fallen derzeit keine Gebühren an. Ein eigenes Speicherkonto ist nur bei direkter Speicherkontrolle nötig; dessen Firewall und Berechtigungen müssen Azure das Schreiben und autorisierten Benutzern das Lesen erlauben.

Untersuche die Startinformationen

Kehre zu Boot diagnostics zurück und öffne Screenshot. Eine fehlerfrei gestartete Ubuntu-VM zeigt normalerweise eine Anmeldeaufforderung. Bei einer fehlerhaften VM können GRUB Rescue, eine Notfall-Shell, eine Kernel Panic oder eine Dateisystemaufforderung sichtbar sein.

Öffne Serial log und untersuche die letzten Meldungen. Suche beispielsweise nach:

FAILED
error
emergency
timeout
panic
No space left on device

Der letzte Fehler ist ein wichtiger Hinweis, lies aber auch die Zeilen davor: Die letzte Meldung kann eine Folge und nicht die Ursache sein. Verwende nach dem Starten oder Neustarten der VM Refresh, da die angezeigten Daten sonst veraltet sein können.

Überprüfe mit Cloud Shell

Bestätige, dass die Startdiagnose aktiviert ist:

az vm show \
  --resource-group rg-cloudtrips-compute-test-weu \
  --name vm-cloudtrips-linux01-test-weu \
  --query "diagnosticsProfile.bootDiagnostics" \
  --output yaml

Erwartetes Ergebnis für verwalteten Speicher:

enabled: true

storageUri kann bei der verwalteten Startdiagnose leer sein. Rufe das serielle Startprotokoll ab, dekodiere den JSON-String und entferne Terminal-Farbcodes:

az vm boot-diagnostics get-boot-log \
  --resource-group rg-cloudtrips-compute-test-weu \
  --name vm-cloudtrips-linux01-test-weu \
  --output json |
  jq -r '.' |
  perl -pe 's/\e\[[0-9;?]*[A-Za-z]//g'

Die rohe Azure-CLI-Antwort kann sonst wie ein langer roter oder verschlüsselter String aussehen, weil sie JSON-Escapes und Terminal-Formatierungscodes enthält. Sie ist nicht verschlüsselt.

Wähle die nächste Wiederherstellungsaktion

Wähle anhand der Hinweise eine gezielte Reparatur. Serial console kann helfen, wenn das Betriebssystem eine verwendbare Konsole erreicht. Bei Datenträger- oder Konfigurationsfehlern, die den Start verhindern, erstelle eine Reparatur-VM oder verbinde eine Kopie des Betriebssystemdatenträgers mit einer anderen VM. Erstelle einen Datenträger-Snapshot, bevor du einen betroffenen Betriebssystemdatenträger änderst.

Lass die verwaltete Startdiagnose aktiviert, damit beim nächsten Vorfall Hinweise verfügbar sind. Dieser Trip erstellt weder eine separate Ressourcengruppe noch ein sichtbares Speicherkonto, das gelöscht werden müsste.