Bekannte Probleme

Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von Compute Engine auftreten können.

Bekannte Probleme bei Linux-VM-Instanzen

Folgende Probleme mit Linux-Images sind bekannt:

GPG-Fehler: EXPKEYSIG 3746C208A7317B0F beim Aktualisieren von Paketen

Auf Debian- und Ubuntu-basierten Systemen, einschließlich Ihrer lokalen Workstations, kann ein ähnlicher Fehler wie im folgenden Beispiel auftreten:

W: An error occurred during the signature verification.
The repository is not updated and the previous index files will be used.
GPG error: http://packages.cloud.google.com/apt cloud-sdk-stretch InRelease:
The following signatures were invalid: EXPKEYSIG 3746C208A7317B0F
Google Cloud Packages Automatic Signing Key <gc-team@google.com>

Durch diesen Fehler wird verhindert, dass Sie die neuesten Updates für mehrere Google Cloud-Tools erhalten, darunter die Folgenden:

Rufen Sie die neueste gültige Schlüsseldatei apt-key.gpg von https://packages.cloud.google.com ab, um diesen Fehler zu beheben:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

Für Compute Engine-VM-Instanzen, auf denen Debian- oder Ubuntu-Images ausgeführt werden, können Sie die neuesten Schlüssel auch erhalten, wenn Sie Ihre Instanzen mit den folgenden Image-Versionen neu erstellen:

  • Image-Projekt debian-cloud:
    • debian-9-stretch-v20180401 oder Image-Familie debian-9
    • debian-8-jessie-v20180401 oder Image-Familie debian-8
  • Image-Projekt ubuntu-os-cloud:
    • ubuntu-1710-artful-v20180315 oder Image-Familie ubuntu-1710
    • ubuntu-1604-xenial-v20180323 oder Image-Familie ubuntu-1604-lts
    • ubuntu-1404-trusty-v20180308 oder Image-Familie ubuntu-1404-lts

Problem mit schreibgeschützten Root-Dateisystemen von Red Hat Enterprise Linux 7 und CentOS 7

VM-Instanzen, auf denen die öffentlichen Images rhel-7-v20170719 und niedriger oder centos-7-v20170719 und niedriger ausgeführt werden, können starten, wenn das Root-Dateisystem im Lesemodus bereitgestellt ist. Anwendungen, Daemons oder Skripts, die Schreibzugriff auf das Root-Dateisystem erfordern, können jedoch nicht starten.

Starten Sie keine laufenden Instanzen neu, die die betroffenen öffentlichen Images verwenden, da sie sonst im Lesemodus verbleiben. Wenn Ihre Instanzen sich bereits im Lesemodus befinden, können Sie den Lese-/Schreibmodus für das Root-Dateisystem per Fernzugriff wiederherstellen und anschließend das Problem beheben.

Betroffene Instanzen ermitteln:

Ermitteln Sie mit den folgenden gcloud compute disks list-Befehlen potenziell betroffene Instanzen:

RHEL 7:

gcloud compute disks list --filter="sourceImage ~ rhel-7-v201[4-6].* OR sourceImage ~ rhel-7-v20170[1-7].*" --uri

CentOS 7:

gcloud compute disks list --filter="sourceImage ~ centos-7-v201[4-6].* OR sourceImage ~ centos-7-v20170[1-7].*" --uri

Wenn diese Laufwerke Ihren Instanzen zugeordnet sind, können Sie das Problem für diese Instanzen beheben. Wie Sie dabei vorgehen müssen, hängt von der Image-Version ab, die Sie zum Erstellen der Instanz verwendet haben.

Bei Instanzen, die mit RHEL 7-Images ab Version rhel-7-v20160418 bis einschließlich rhel-7-v20170719 oder mit CentOS 7-Images ab Version centos-7-v20160418 bis einschließlich centos-7-v20170719 erstellt wurden, gehen Sie so vor:

Wenn für die Instanz automatische Updates aktiviert sind, entfernt yum-cron automatisch die fehlerhafte Bereitstellungsoption aus der Datei /etc/fstab und behebt den Fehler durch Installieren eines fehlerfreien Pakets. Wenn für die Instanz keine automatischen Updates aktiviert sind, können Sie den Fehler so beheben:

  1. Stellen Sie über SSH eine Verbindung zur Instanz her. Wenn die Verbindung fehlschlägt, befindet sich die Instanz möglicherweise im Lesemodus. Sie können jedoch versuchen, den Lese-/Schreibmodus wiederherzustellen. Wenn Sie vorher schon einmal eine SSH-Verbindung zur betroffenen Instanz hergestellt haben, wurden Ihre öffentlichen SSH-Schlüssel bereits im Root-Dateisystem gespeichert und funktionieren weiterhin. Führen Sie über ssh einen Remotebefehl aus, um das Dateisystem im rw-Modus noch einmal bereitzustellen. Sie können beispielsweise den folgenden Befehl in gcloud verwenden, um das Root-Dateisystem noch einmal bereitzustellen:

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"
    

    Sobald sich das Dateisystem wieder im Lese-/Schreibmodus befindet, stellen Sie über SSH eine Verbindung zur Instanz her.

  2. Führen Sie sudo yum -y update aus, um alle installierten Pakete einschließlich des Pakets gce-disk-expand zu aktualisieren, das der Fehlerbehebung dient.

Sie können die Instanz nun noch einmal starten, ohne dass das Root-Dateisystem im Lesemodus bereitgestellt wird.

Bei Instanzen, die mit RHEL 7-Images vor der Version rhel-7-v20160418 oder mit CentOS 7-Images vor der Version centos-7-v20160418 erstellt wurden, gehen Sie so vor:

  1. Stellen Sie über SSH eine Verbindung zur Instanz her. Wenn die Verbindung fehlschlägt, befindet sich die Instanz möglicherweise im Lesemodus. Sie können jedoch versuchen, den Lese-/Schreibmodus wiederherzustellen. Wenn Sie vorher schon einmal eine SSH-Verbindung zur betroffenen Instanz hergestellt haben, wurden Ihre öffentlichen SSH-Schlüssel bereits im Root-Dateisystem gespeichert und funktionieren weiterhin. Führen Sie über ssh einen Remotebefehl aus, um das Dateisystem im rw-Modus noch einmal bereitzustellen. Sie können beispielsweise den folgenden Befehl in gcloud verwenden, um das Root-Dateisystem noch einmal bereitzustellen:

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"
    

    Sobald sich das Dateisystem wieder im Lese-/Schreibmodus befindet, stellen Sie über SSH eine Verbindung zur Instanz her.

  2. Bearbeiten Sie die Datei /etc/fstab und entfernen Sie alle Bereitstellungsoptionen des Typs barrier=1 in dieser Datei. Nur die Bereitstellungsoption default darf als Eintrag für das Root-Dateisystem festgelegt sein. Sie können diese fehlerhafte Bereitstellungsoption mithilfe des folgenden Befehls korrigieren:

    sudo sed -i 's/defaults,barrier[^ ,]*/defaults/' /etc/fstab
    

    Nachdem Sie die Bereitstellungsoption barrier=1 entfernt haben, sollte in der Datei /etc/fstab der Eintrag für das Root-Dateisystem folgendem Beispiel ähneln, abgesehen vom UUID-Wert:

    UUID=b5e54172-67e3-4d52-95f4-4314e71b25fd / xfs defaults 0 0
    

Sie können die Instanz nun noch einmal starten, ohne dass das Root-Dateisystem im Lesemodus bereitgestellt wird.

Nicht abwärtskompatible Änderung durch CentOS-Image v20131120 bei standardmäßiger Aktivierung von iptables

Der Release v20131120 des CentOS 6-Image centos-6-v20131120 enthält eine nicht abwärtskompatible Änderung, bei der iptables standardmäßig aktiviert werden. Dadurch wird verhindert, dass externer Traffic CentOS-Instanzen erreicht, auf denen centos-6-v20131120 ausgeführt wird, selbst wenn eine vorhandene Firewallregelressource die Verbindung erlaubt.

Zur Umgehung des Problems müssen die Nutzer iptables entweder deaktivieren oder dahingehend aktualisieren, dass die gewünschte Verbindung (zusätzlich zum Datenverkehr, der durch die Firewallregeln zugelassen ist) erlaubt wird. Führen Sie zum Deaktivieren von iptables Folgendes aus:

# Save your iptable settings
user@centos-instance:~$ sudo service iptables save
# Stop the iptables service
user@centos-instance:~$ sudo service iptables stop
# Disable iptables on start up
user@centos-instance:~$ sudo chkconfig iptables off

Zum Aktualisieren von iptables richten Sie sich nach der iptables-Dokumentation.

Von Google bereitgestellte Images haben ein bekanntes Problem mit dem Treiber ext4/scsi in den stabilen Debian- und CentOS-Kerneln

Bei den Images "centos-6-v20131120" und "debian-7-wheezy-v20131120" kann ein bekannter ext4-Fehler zu einem Speicherleck und bei starker Auslastung des nichtflüchtigen Speichers schließlich zum Absturz einer VM-Instanz führen. Ausführliche Informationen dazu finden Sie in dieser Linux-Kernel-Mailing-Liste.

Instanznamen mit mehr als 32 Zeichen verursachen Probleme bei UNIX-Tools

Datum des Berichts: Juni 2012

Instanznamen können zwar bis zu 63 Zeichen lang sein, doch ist es möglich, dass Namen von mehr als 32 Zeichen zu unzuverlässigem Verhalten bestimmter Tools führen. Dies betrifft auch einige Tools, die beim Booten ausgeführt werden. Wählen Sie zur Vermeidung dieses Problems Instanznamen, die kürzer als 32 Zeichen sind.

Instanzen, die OS Login verwenden, geben nach der Verbindung eine Fehlermeldung zurück

Auf einigen Instanzen, die OS Login verwenden, erhalten Sie möglicherweise die folgende Fehlermeldung, nachdem die Verbindung hergestellt wurde:

/usr/bin/id: cannot find name for group ID 123456789

Ignorieren Sie die Fehlermeldung.

Bekannte Probleme für Windows-VM-Instanzen

Nachfolgende Liste enthält einige bekannte Probleme mit Windows-Images:

  • Obwohl Windows-Instanzen die NVMe-Schnittstelle mit einer lokalen SSD nutzen können, befindet sich die Unterstützung von NVMe unter Windows noch in der Betaphase und wir können nicht dieselbe Leistung wie bei Linux-Instanzen garantieren.
  • Auf Windows 2008 R2 benötigt die Installation von Python 2.7.9 oder höher Visual C++. Unter Python 2.7.8 besteht diese Notwendigkeit nicht, es wird jedoch empfohlen, die neueste Version zu installieren.
  • Compute Engine unterstützt derzeit noch kein IPv6. Selbst, wenn Sie IPv6 durch Auswahl dieser Option auf einer Windows-Instanz aktivieren, wird die Einstellung ignoriert.
  • Nachdem eine neue Instanz erstellt wurde, können Sie nicht sofort eine Verbindung zu ihr herstellen. Alle neuen Windows-Instanzen verwenden das Systemvorbereitungs-Tool sysprep zum Einrichten der Instanz, das dafür 5–10 Minuten benötigt.
  • Windows Server-Images können nur bei einer bestehenden Netzwerkverbindung zu kms.windows.googlecloud.com aktiviert werden und stellen nach 30 Tagen ihre Funktion ein, wenn sie nicht bis dahin authentifiziert worden sind. Über KMS aktivierte Software muss alle 180 Tage reaktiviert werden. Der KMS versucht jedoch, alle 7 Tage eine Reaktivierung durchzuführen. Erstellen Sie eine externe IP-Adresse für Ihre Windows-Instanzen, damit diese sich regelmäßig authentifizieren können.
  • Wenn Kernelsoftware auf nicht emulierte modellspezifische Register zugreift, erzeugt dies allgemeine Schutzverletzungen, die je nach Gastbetriebssystem einen Systemabsturz verursachen können.
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation