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

Die folgenden bekannten Probleme treten bei Linux-Images auf.

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:

Um diesen Fehler zu beheben, rufen Sie die neueste gültige apt-key.gpg-Schlüsseldatei von https://packages.cloud.google.com mit dem folgenden Befehl ab:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo 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:

  • debian-cloud-Imageprojekt:
    • debian-9-stretch-v20180401 oder Imagefamilie debian-9
    • debian-8-jessie-v20180401 oder Imagefamilie debian-8
  • ubuntu-os-cloud-Imageprojekt:
    • ubuntu-1710-artful-v20180315 oder Imagefamilie 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, die öffentliche Images rhel-7-v20170719 oder früher oder centos-7-v20170719 oder früher ausführen, können mit dem Root-Dateisystem im schreibgeschützten Modus gestartet werden. Anwendungen, Daemons oder Skripts, die Schreibzugriff auf das Root-Dateisystem benötigen, schlagen fehl.

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

Betroffene Instanzen ermitteln:

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

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 Imageversion ab, die Sie zum Erstellen der Instanz verwendet haben.

Instanzen, die mithilfe von RHEL 7-Images zwischen rhel-7-v20160418 und rhel-7-v20170719 oder CentOS 7-Images zwischen centos-7-v20160418 und centos-7-v20170719 erstellt wurden:

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. Verbindung zur Instanz über SSH herstellen Wenn die Verbindung fehlschlägt, bleibt die Instanz möglicherweise im schreibgeschützten Modus. 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 einen Remote-Befehl über ssh aus, um das Dateisystem im rw-Modus noch einmal bereitzustellen. Sie können z. B. mit dem folgenden gcloud-Befehl das Root-Dateisystem wiederherstellen:

    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. Aktualisieren Sie alle installierten Pakete mit sudo yum -y update, einschließlich des Pakets gce-disk-expand mit dem Fehler.

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

Instanzen, die mit RHEL 7-Images vor rhel-7-v20160418 erstellt wurden, oder die mit CentOS 7-Images vor centos-7-v20160418 erstellt wurden:

  1. Verbindung zur Instanz über SSH herstellen Wenn die Verbindung fehlschlägt, bleibt die Instanz möglicherweise im schreibgeschützten Modus. 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 einen Remote-Befehl über ssh aus, um das Dateisystem im rw-Modus noch einmal bereitzustellen. Sie können z. B. mit dem folgenden gcloud-Befehl das Root-Dateisystem wiederherstellen:

    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 /etc/fstab-Datei und entfernen Sie alle barrier=1-Bereitstellungsoptionen in dieser Datei. Nur die default-Bereitstellungsoption 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 barrier=1-Bereitstellungsoption entfernt haben, sollte der Stammdateisystemeintrag in der /etc/fstab-Datei dem folgenden Beispiel mit einem anderen Wert für die UUID ähneln:

    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.

CentOS-Image v20131120 hat eine funktionsgefährdende Änderung eingeführt, bei der iptables standardmäßig aktiviert ist

Die v20131120-Version des CentOS 6-Images, centos-6-v20131120, weist eine wichtige Änderung auf, wobei iptables standardmäßig aktiviert ist. 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.

Als Behelfslösung können Nutzer iptables deaktivieren oder aktualisieren, um die gewünschte Verbindung zuzulassen – zusätzlich zum Zulassen des Traffics mithilfe von Firewallregeln. Führen Sie die folgenden Befehle aus, um iptables zu deaktivieren:

# 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

Von Google bereitgestellte Images haben ein bekanntes Problem mit dem ext4/scsi-Treiber 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 finden Sie im Thread Question about ext4 excessive stall time (Frage zu übermäßigen Wartezeiten mit ext4) auf der Linux-Kernel-Mailingliste.

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

Datum des Berichts: Juni 2012

Instanznamen dürfen zwar bis zu 63 Zeichen lang sein, doch Namen von mehr als 32 Zeichen können 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

Die folgenden bekannten Probleme treten bei Windows-Images auf:

  • Obwohl Windows-Instanzen die NVMe-Schnittstelle mit lokalen SSDs verwenden können, ist die NVMe-Unterstützung unter Windows in der Betaphase. Die gleiche Leistung wie bei Linux-Instanzen kann nicht garantiert werden.
  • Auf Windows Server 2008 R2 benötigt die Installation von Python 2.7.9 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 Sie eine Instanz erstellt haben, 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 bis dahin nicht authentifiziert wurden. Über KMS aktivierte Software muss alle 180 Tage reaktiviert werden. Der KMS versucht jedoch, alle 7 Tage eine Reaktivierung durchzuführen. Achten Sie darauf, dass Sie Ihre Windows-Instanzen so konfigurieren, dass sie aktiviert bleiben.
  • Wenn Kernelsoftware auf nicht emulierte modellspezifische Register zugreift, erzeugt dies allgemeine Schutzverletzungen, die je nach Gastbetriebssystem einen Systemabsturz verursachen können.