Fehlerbehebung für SSH

In diesem Dokument werden häufige Fehler beschrieben, die beim Herstellen einer Verbindung zu Linux-VM-Instanzen über SSH auftreten können, Möglichkeiten zur Behebung von Fehlern und Methoden zur Diagnose fehlgeschlagener SSH-Verbindungen.

Häufige SSH-Fehler

Im Folgenden finden Sie Beispiele für häufige Fehler, die bei der Verwendung von SSH zur Verbindung mit Compute Engine-VMs auftreten können.

Berechtigung verweigert

Der folgende Fehler kann auftreten, wenn Sie eine Verbindung zu Ihrer VM herstellen:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Dieser Fehler kann aus verschiedenen Gründen auftreten. Das sind die häufigsten Ursachen für diesen Fehler:

  • Sie haben einen in den Metadaten gespeicherten SSH-Schlüssel verwendet, um eine Verbindung zu einer VM herzustellen, bei der OS Login aktiviert ist. Wenn OS Login in Ihrem Projekt aktiviert ist, akzeptiert Ihre VM keine SSH-Schlüssel, die in Metadaten gespeichert sind.

    Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

  • Sie haben einen SSH-Schlüssel verwendet, der in einem OS Login-Profil gespeichert ist, um eine Verbindung zu einer VM herzustellen, bei der OS Login nicht aktiviert ist. Wenn Sie OS Login deaktivieren, akzeptiert Ihre VM keine SSH-Schlüssel, die in Ihrem OS Login-Profil gespeichert wurden.

    Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

  • Ihr Schlüssel ist abgelaufen und Compute Engine hat die Datei ~/.ssh/authorized_keys gelöscht. Wenn Sie Ihrer VM manuell SSH-Schlüssel hinzugefügt und dann über die Google Cloud Console eine Verbindung zu Ihrer VM hergestellt haben, hat Compute Engine ein neues Schlüsselpaar für Ihre Verbindung erstellt. Nach dem Ablauf des neuen Schlüsselpaars hat Compute Engine Ihre ~/.ssh/authorized_keys-Datei in der VM gelöscht, die Ihren manuell hinzugefügten SSH-Schlüssel enthielt.

    Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

  • Die Verbindung wurde mit einem Drittanbietertool hergestellt und der SSH-Befehl ist falsch konfiguriert. Wenn Sie eine Verbindung mit dem Befehl ssh herstellen, aber keinen Pfad zum privaten Schlüssel angeben oder einen falschen Pfad zum privaten Schlüssel angeben, lehnt die VM Ihre Verbindung ab.

    Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben:

    • Führen Sie dazu diesen Befehl aus:
      ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP
      

      Dabei gilt:
      • PATH_TO_PRIVATE_KEY ist der Pfad zur privaten SSH-Schlüsseldatei.
      • USERNAME ist der Name des Nutzers, der eine Verbindung zur Instanz herstellt. Wenn Sie Ihre SSH-Schlüssel in Metadaten verwalten, muss dies der Nutzername sein, den Sie beim Erstellen des SSH-Schlüssels angegeben haben. Für OS Login-Konten wird der Nutzername in Ihrem Google-Profil festgelegt.
      • EXTERNAL_IP ist die externe IP-Adresse für Ihre Instanz.
    • Stellen Sie mit der Google Cloud Console oder dem gcloud-Befehlszeilentool eine Verbindung zur VM her. Wenn Sie über diese Tools eine Verbindung herstellen, verwaltet Compute Engine die Schlüsselerstellung für Sie. Weitere Informationen finden Sie unter Verbindung zu VMs herstellen.
  • Die Gastumgebung Ihrer VM wird nicht ausgeführt. Wenn Sie sich zum ersten Mal mit Ihrer VM verbinden und die Gastumgebung nicht ausgeführt wird, lehnt die VM möglicherweise die SSH-Verbindungsanfrage ab.

    So beheben Sie das Problem:

    1. Starten Sie die VM neu.
    2. Prüfen Sie in der Cloud Console die Systemstartlogs in der Ausgabe des seriellen Ports, um festzustellen, ob die Gastumgebung ausgeführt wird. Weitere Informationen finden Sie unter Gastumgebung validieren.
    3. Wenn die Gastumgebung nicht ausgeführt wird, installieren Sie die Gastumgebung manuell, indem Sie das Bootlaufwerk der VM klonen und ein Startskript verwenden.
  • Der sshd-Daemon wird nicht ausgeführt oder ist nicht ordnungsgemäß konfiguriert. Der sshd-Daemon aktiviert SSH-Verbindungen. Ist er falsch konfiguriert oder wird nicht ausgeführt, können Sie keine Verbindung zur VM herstellen.

    Prüfen Sie anhand des Nutzerhandbuchs für Ihr Betriebssystem, ob sshd_config korrekt eingerichtet ist.

Verbindungsfehler

Die folgenden Fehler können auftreten, wenn Sie über die Google Cloud Console oder das gcloud-Tool eine Verbindung zur VM herstellen:

  • Cloud Console

    Connection Failed
    
    We are unable to connect to the VM on port 22.
    
  • Das gcloud-Tool:

    ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
    

Diese Fehler können aus verschiedenen Gründen auftreten. Im Folgenden finden Sie einige der häufigsten Ursachen dafür:

  • Die VM wird gestartet und sshd wird noch nicht ausgeführt. Sie können keine Verbindung zu einer VM herstellen, bevor diese ausgeführt wird.

    Lösung: Warten Sie, bis die VM gestartet wurde und versuchen Sie dann noch einmal, eine Verbindung herzustellen.

  • Die Firewallregel, die SSH zulässt, fehlt oder ist falsch konfiguriert. Standardmäßig erlauben Compute Engine-VMs den SSH-Zugriff auf Port 22. Wenn die Regel default-allow-ssh fehlt oder falsch konfiguriert ist, können Sie keine Verbindung zu VMs herstellen.

    Lösung: Prüfen Sie Ihre Firewallregeln und fügen Sie default-allow-ssh neu hinzu oder konfigurieren Sie es neu.

  • sshd wird auf einem benutzerdefinierten Port ausgeführt. Wenn Sie sshd für die Ausführung auf einem anderen Port als Port 22 konfiguriert haben, können Sie keine Verbindung zu Ihrer VM herstellen.

    Lösung: Erstellen Sie eine benutzerdefinierte Firewallregel, die tcp-Traffic auf dem Port zulässt, auf dem Ihr sshd mit dem folgenden Befehl ausgeführt wird:

    gcloud compute firewall-rules create FIREWALL_NAME \
      --allow tcp:PORT_NUMBER
    

    Weitere Informationen zum Erstellen benutzerdefinierter Firewallregeln finden Sie unter Firewallregeln erstellen.

  • Ihre benutzerdefinierte SSH-Firewallregel lässt keinen Traffic von Google-Diensten zu. SSH-Verbindungen von der Cloud Console werden abgelehnt, wenn benutzerdefinierte Firewallregeln keine Verbindungen aus dem IP-Adressbereich von Google zulassen.

    So beheben Sie das Problem:

    1. Tragen Sie die IP-Adressbereiche von Google mit dem folgenden Befehl zusammen:

      dig +qr +short txt `dig +short TXT _spf.google.com | grep -oE 'include:\S*' | cut -d':' -f2 | xargs` | grep -oE 'ip[46]:\S*' | sort | uniq
      
    2. Aktualisieren Sie Ihre benutzerdefinierte Firewallregel, um Traffic von Google-IP-Adressen zuzulassen. Weitere Informationen finden Sie unter Firewallregeln aktualisieren.

  • Die SSH-Verbindung ist nach dem Upgrade des VM-Kernels fehlgeschlagen. Bei einer VM kann es nach einem Kernelupdate zu einer Kernel Panic kommen, wodurch die VM nicht mehr zugänglich ist.

    So beheben Sie das Problem:

    1. Stellen Sie das Laufwerk auf einer anderen VM bereit.
    2. Aktualisieren Sie die Datei grub.cfg, um die vorherige Version des Kernels zu verwenden.
    3. Hängen Sie das Laufwerk an die nicht reagierende VM an.
    4. Prüfen Sie mit dem Befehl gcloud compute instances describe, ob der Status der VM RUNNING lautet.
    5. Installieren Sie den Kernel neu.
    6. Starten Sie die VM neu.

    Wenn Sie vor dem Upgrade der VM einen Snapshot des Bootlaufwerks erstellt haben, verwenden Sie alternativ den Snapshot zum Erstellen einer VM.

  • Der sshd-Daemon wird nicht ausgeführt oder ist nicht ordnungsgemäß konfiguriert. Der sshd-Daemon aktiviert SSH-Verbindungen. Ist er falsch konfiguriert oder wird nicht ausgeführt, können Sie keine Verbindung zur VM herstellen.

    Prüfen Sie anhand des Nutzerhandbuchs für Ihr Betriebssystem, ob sshd_config korrekt eingerichtet ist.

  • Die VM wird nicht gestartet und Sie können keine Verbindung über SSH oder die serielle Konsole herstellen. Wenn die VM nicht zugänglich ist, ist Ihr Betriebssystem möglicherweise beschädigt. Wenn das Bootlaufwerk nicht gestartet wird, können Sie das Problem diagnostizieren. Informationen zum Wiederherstellen der beschädigten VM und zum Abrufen von Daten finden Sie unter Beschädigte VM oder vollständiges Bootlaufwerk wiederherstellen.

  • Die VM wird im Wartungsmodus gestartet. Beim Booten im Wartungsmodus akzeptiert die VM keine SSH-Verbindungen. Sie können jedoch eine Verbindung zur seriellen Konsole der VM herstellen und sich als Root-Nutzer anmelden.

    So beheben Sie das Problem:

    1. Wenn Sie kein Root-Passwort für die VM festgelegt haben, verwenden Sie ein Metadaten-Startskript, um während des Starts den folgenden Befehl auszuführen:

      echo "NEW_PASSWORD" | chpasswd

      Ersetzen Sie NEW_PASSWORD durch ein Passwort Ihrer Wahl.

    2. Starten Sie die VM neu.

    3. Stellen Sie eine Verbindung zur seriellen Konsole der VM her und melden Sie sich als Root-Nutzer an.

Verbindung zum Back-End konnte nicht hergestellt werden

Die folgenden Fehler können auftreten, wenn Sie über die Google Cloud Console oder das gcloud-Tool eine Verbindung zur VM herstellen:

  • Cloud Console

    -- Connection via Cloud Identity-Aware Proxy Failed
    
    -- Code: 4003
    
    -- Reason: failed to connect to backend
    
  • Das gcloud-Tool:

    ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: u'failed to connect to backend'].
    

Diese Fehler treten auf, wenn Sie versuchen, mithilfe von SSH eine Verbindung zu einer VM herzustellen, die keine öffentliche IP-Adresse hat und bei der Sie Identity-Aware Proxy nicht auf Port 22 konfiguriert haben.

Lösung: Erstellen Sie eine Firewallregel auf Port 22, die eingehenden Traffic von Identity-Aware Proxy zulässt.

Fehlerhafte SSH-Verbindungen diagnostizieren

In den folgenden Abschnitten werden die Schritte beschrieben, die Sie ausführen können, um die Ursache fehlerhafter SSH-Verbindungen zu diagnostizieren und diese Fehler zu beheben.

Gehen Sie folgendermaßen vor, bevor Sie fehlgeschlagene SSH-Verbindungen diagnostizieren:

Verbindung testen

Es kann vorkommen, dass Sie aufgrund von Verbindungsproblemen, die mit Firewalls, Netzwerkverbindungen oder dem Nutzerkonto zusammenhängen, keine SSH-Verbindung zu einer VM-Instanz herstellen können. Die Schritte dieses Abschnitts bieten die Möglichkeit, die jeweiligen Ursachen für die Verbindungsprobleme zu ermitteln.

Firewallregeln prüfen

Compute Engine stellt für jedes Projekt eine Gruppe standardmäßiger Firewallregeln bereit, die Traffic über SSH erlauben. Wenn Sie nicht auf die Instanz zugreifen können, prüfen Sie mit dem gcloud compute-Befehlszeilentool Ihre Liste der Firewalls und achten Sie darauf, dass die Regel default-allow-ssh vorhanden ist.

Führen Sie auf Ihrer lokalen Workstation den folgenden Befehl aus:

gcloud compute firewall-rules list

Sollte die Regel fehlen, fügen Sie sie wieder hinzu:

gcloud compute firewall-rules create default-allow-ssh \
    --allow tcp:22

Verwenden Sie den Befehl gcloud compute firewall-rules describe, um sich alle Daten anzeigen zu lassen, die mit der Firewallregel default-allow-ssh in Ihrem Projekt verknüpft sind:

gcloud compute firewall-rules describe default-allow-ssh \
    --project=project-id

Weitere Informationen zu Firewallregeln finden Sie unter Firewallregeln in Google Cloud.

Netzwerkverbindung testen

Testen Sie den TCP-Handshake, um festzustellen, ob die Netzwerkverbindung funktioniert:

  1. Rufen Sie die externe natIP für Ihre VM ab:

    gcloud compute instances describe VM_NAME \
        --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
    

    Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

  2. Testen Sie die Netzwerkverbindung zu Ihrer VM von Ihrer Workstation aus:

    Linux, Windows 2019 und macOS

    curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER
    

    Dabei gilt:

    • EXTERNAL_IP: die externe IP-Adresse, die Sie im vorherigen Schritt abgerufen haben
    • PORT_NUMBER: die Portnummer

    Wenn der TCP-Handshake erfolgreich ist, sieht die Ausgabe in etwa so aus:

    Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
    Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
    Trying 192.168.0.4...
    TCP_NODELAY set
    Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
    Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
    > GET / HTTP/1.1
    > Host: 192.168.0.4:443
    > User-Agent: curl/7.64.0
    > Accept: */*
    >
    Empty reply from server
    Connection #0 to host 192.168.0.4 left intact
    

    Die Zeile Connected to zeigt einen erfolgreichen TCP-Handshake an.

    Windows 2012 und 2016

    PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)
    

    Dabei gilt:

    • EXTERNAL_IP: die externe IP-Adresse, die Sie im vorherigen Schritt erhalten haben
    • PORT_NUMBER: die Portnummer

    Wenn der TCP-Handshake erfolgreich ist, sieht die Ausgabe in etwa so aus:

    Available           : 0
    Client              : System.Net.Sockets.Socket
    Connected           : True
    ExclusiveAddressUse : False
    ReceiveBufferSize   : 131072
    SendBufferSize      : 131072
    ReceiveTimeout      : 0
    SendTimeout         : 0
    LingerState         : System.Net.Sockets.LingerOption
    NoDelay             : False
    

    Die Zeile Connected: True zeigt einen erfolgreichen TCP-Handshake an.

Wenn der TCP-Handshake erfolgreich abgeschlossen wurde, wird die Verbindung nicht durch eine Software-Firewall-Regel blockiert, das Betriebssystem leitet die Pakete korrekt weiter und ein Server überwacht den Zielport. Wenn der TCP-Handshake erfolgreich abgeschlossen wurde, die VM jedoch keine SSH-Verbindungen akzeptiert, ist der Daemon sshd möglicherweise falsch konfiguriert oder wird nicht ordnungsgemäß ausgeführt. Prüfen Sie anhand des Benutzerhandbuchs für Ihr Betriebssystem, ob sshd_config korrekt eingerichtet ist.

Um Konnektivitätstests zur Analyse der VPC-Netzwerkpfadkonfiguration zwischen zwei VMs auszuführen und zu prüfen, ob die programmierte Konfiguration den Traffic zulassen sollte, beachten Sie Auf falsch konfigurierte Firewallregeln in Google Cloud prüfen.

Nutzer für eine Verbindung ändern

Eine fehlgeschlagene Anmeldung ist möglicherweise auf das verwendete Nutzerkonto zurückzuführen. Es kann beispielsweise sein, dass die Berechtigungen in der Datei ~/.ssh/authorized_keys der Instanz für den Nutzer nicht ordnungsgemäß festgelegt wurden.

Melden Sie sich zur Klärung mit dem gcloud-Tool als ein anderer Nutzer an. Ersetzen Sie dabei in der SSH-Anfrage ANOTHER_USERNAME durch einen anderen Nutzernamen. Das gcloud-Tool aktualisiert die Metadaten des Projekts, um den neuen Nutzer hinzuzufügen und den SSH-Zugriff zuzulassen.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Dabei gilt:

  • ANOTHER_USERNAME ist ein Nutzername, der nicht Ihr eigener Nutzername ist.
  • VM_NAME ist der Name der VM, zu der Sie eine Verbindung herstellen möchten.

Fehler mithilfe der seriellen Konsole beheben

Wir empfehlen Ihnen, die Logs der seriellen Konsole auf Verbindungsfehler zu prüfen. Von Ihrer lokalen Workstation aus können Sie mit einem Browser auf die serielle Konsole zugreifen.

Aktivieren Sie den Lese-/Schreibzugriff auf die serielle Konsole einer Instanz, damit Sie sich bei der Konsole anmelden und Probleme mit der Instanz beheben können. Dies ist nützlich, wenn eine Anmeldung mit SSH nicht möglich ist oder die Instanz keine Verbindung zum Netzwerk hat. Die serielle Konsole ist in beiden Situationen zugänglich.

Wie Sie interaktiven Zugriff aktivieren und eine Verbindung zur seriellen Konsole einer Instanz herstellen, erfahren Sie unter Mit der seriellen Konsole interagieren.

VM-Instanz ohne Herunterfahren prüfen

Es kann sein, dass Sie keine Verbindung zu einer Instanz herstellen können, obwohl sie Produktionstraffic weiterhin fehlerfrei verarbeitet. In einer solchen Situation müssen Sie das Laufwerk prüfen, ohne die Instanz zu unterbrechen.

So prüfen und reparieren Sie das Laufwerk:

  1. Sichern Sie das Bootlaufwerk dadurch, dass Sie einen Snapshot des Laufwerks erstellen.
  2. Erstellen Sie anhand dieses Snapshots einen regulären nichtflüchtigen Speicher.
  3. Erstellen Sie eine temporäre Instanz.
  4. Hängen Sie den regulären nichtflüchtigen Speicher an Ihre neue temporäre Instanz an und stellen Sie ihn bereit.

Bei dieser Vorgehensweise entsteht ein isoliertes Netzwerk, das nur SSH-Verbindungen zulässt. Dadurch wird verhindert, dass unbeabsichtigte Folgen bei der Erstellung der geklonten Instanz Ihre Produktionsdienste beeinträchtigen.

  1. Erstellen Sie ein neues VPC-Netzwerk, in dem die geklonte Instanz gehostet werden kann:

    gcloud compute networks create debug-network
    

    Ersetzen Sie NETWORK_NAME durch den Namen für das neue Netzwerk.

  2. Fügen Sie eine Firewallregel hinzu, die SSH-Verbindungen zum Netzwerk zulässt:

    gcloud compute firewall-rules create debug-network-allow-ssh \
       --network debug-network \
       --allow tcp:22
    
  3. Erstellen Sie einen Snapshot des Bootlaufwerks.

    gcloud compute disks snapshot BOOT_DISK_NAME \
       --snapshot-names debug-disk-snapshot
    

    Ersetzen Sie BOOT_DISK_NAME durch den Namen des Bootlaufwerks.

  4. Erstellen Sie mit dem Snapshot aus dem vorigen Schritt ein neues Laufwerk:

    gcloud compute disks create example-disk-debugging \
       --source-snapshot debug-disk-snapshot
    
  5. Erstellen Sie eine neue Debug-Instanz ohne externe IP-Adresse:

    gcloud compute instances create debugger \
       --network debug-network \
       --no-address
    
  6. Fügen Sie der Instanz das Debug-Laufwerk hinzu:

    gcloud compute instances attach-disk debugger \
       --disk example-disk-debugging
    
  7. Folgen Sie den Anweisungen zum Herstellen einer Verbindung zu einer Instanz ohne externe IP-Adresse.

  8. Nach der Anmeldung bei der Debugger-Instanz führen Sie die Fehlerbehebung für die Instanz durch. Prüfen Sie zum Beispiel die Instanzlogs:

    sudo su -
    
    mkdir /mnt/VM_NAME
    
    mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME
    
    cd /mnt/VM_NAME/var/log
    
    # Identify the issue preventing ssh from working
    ls
    

    Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

Startskript verwenden

Wenn keiner der vorherigen Vorschläge weitergeholfen hat, können Sie ein Startskript erstellen, um Informationen unmittelbar nach dem Start der Instanz zu erfassen. Folgen Sie der Anleitung zum Ausführen von Startskripts.

Anschließend müssen Sie mit gcloud compute instances reset die Instanz zurücksetzen, damit die Metadaten wirksam werden.

Alternativ können Sie die Instanz auch neu erstellen, indem Sie ein Diagnose-Startskript ausführen:

  1. Führen Sie gcloud compute instances delete mit dem Flag --keep-disks aus.

    gcloud compute instances delete VM_NAME \
       --keep-disks boot
    

    Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

  2. Fügen Sie eine neue Instanz mit demselben Laufwerk hinzu und geben Sie das Startskript an.

    gcloud compute instances create NEW_VM_NAME \
       --disk name=BOOT_DISK_NAME,boot=yes \
       --metadata startup-script-url URL
    

    Dabei gilt:

    • NEW_VM_NAME ist der Name der neuen VM, die Sie erstellen.
    • BOOT_DISK_NAME ist der Name des Bootlaufwerks von der VM, zu der Sie keine Verbindung herstellen können.
    • URL ist die Cloud Storage-URL zum Skript, entweder im Format gs://BUCKET/FILE oder https://storage.googleapis.com/BUCKET/FILE.

Laufwerk auf einer neuen Instanz verwenden

Wenn Sie immer noch Daten von Ihrem nichtflüchtigen Bootlaufwerk wiederherstellen müssen, können Sie das Bootlaufwerk trennen und als sekundäres Laufwerk an eine neue Instanz anhängen.

  1. Löschen Sie die VM, zu der Sie keine Verbindung herstellen können, und behalten Sie ihr Bootlaufwerk bei:

    gcloud compute instances delete VM_NAME \
       --keep-disks=boot 

    Ersetzen Sie VM_NAME durch den Namen der VM, zu der Sie keine Verbindung herstellen können.

  2. Erstellen Sie eine neue VM mit dem alten VM-Bootlaufwerk:

    gcloud compute instances create NEW_VM_NAME \
       --disk name=BOOT_DISK_NAME,boot=yes,auto-delete=no 

    Dabei gilt:

    • NEW_VM_NAME ist der Name der neuen VM, die Sie erstellen.
    • BOOT_DISK_NAME ist der Name des Bootlaufwerks von der VM, zu der Sie keine Verbindung herstellen können.
  3. Stellen Sie über SSH eine Verbindung zu Ihrer neuen VM her.

    gcloud compute ssh NEW_VM_NAME
    

    Ersetzen Sie dabei NEW_VM_NAME durch den Namen der neuen VM.

Prüfen, ob das VM-Bootlaufwerk voll ist

Ihre VM ist möglicherweise nicht mehr zugänglich, wenn das Bootlaufwerk voll ist. Die Fehlerbehebung für dieses Szenario kann schwierig sein, da nicht immer klar ist, ob das Problem mit der VM-Verbindung auf ein volles Bootlaufwerk zurückzuführen ist. Weitere Informationen zu diesem Szenario finden Sie unter Fehlerbehebung bei einer VM, die aufgrund eines vollen Bootlaufwerks nicht zugänglich ist.

Nächste Schritte