Bekannte Probleme

Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von Compute Engine-Instanzen auftreten können. Informationen zu Problemen, die sich speziell auf Confidential VMs auswirken, finden Sie unter Einschränkungen von Confidential VMs.

Allgemeine Probleme

Die folgenden Probleme enthalten Anleitungen zur Fehlerbehebung oder allgemeine Informationen.

Compute-Instanzen mit aktiviertem Secure Boot können möglicherweise nicht gestartet werden

In seltenen Fällen kann es vorkommen, dass Shielded VM-Instanzen, die vor dem 7. November 2025 mit aktiviertem Secure Boot erstellt wurden oder die Software zur vollständigen Laufwerkverschlüsselung oder Secret Sealing für vTPM-PCRs verwenden, nicht gestartet werden können. Dies kann durch eine falsche Reihenfolge von Updates verursacht werden (z. B. durch das Aktualisieren von Shim ohne gültige Zertifikate), nachdem die Microsoft Secure Boot-Zertifikate in der zweiten Hälfte des Jahres 2026 abgelaufen sind.

Lösung

Aktualisieren Sie Ihre Compute-Instanzen mit den neuen Zertifikaten, um dieses Problem zu beheben. Weitere Informationen finden Sie im Leitfaden zum Ablauf von Microsoft Secure Boot-Zertifikaten.

Bei lokalen SSD-Laufwerken, die an C4A-, C4D-, C4- und H4D-Instanzen angehängt sind, werden bei einem Stromausfall möglicherweise nicht alle Schreibvorgänge erfasst.

Wenn nach einem Stromausfall auf einem Hostserver die Daten auf den lokalen SSD-Laufwerken wiederhergestellt werden können, wird eine Compute Engine-Instanz, die auf diesem Hostserver ausgeführt wird, mit allen angehängten Laufwerken neu gestartet. Die Daten umfassen alle Schreibvorgänge, die vor dem Hostfehler abgeschlossen wurden.

Bei C4A-, C4D-, C4- und H4D-Instanzen enthalten die wiederhergestellten lokalen SSD-Laufwerke möglicherweise keine Schreibvorgänge, die unmittelbar vor dem Stromausfall abgeschlossen wurden. Wenn die Compute-Instanz neu gestartet wird, wird beim Lesen aus einer betroffenen logischen Blockadresse (Logical Block Address, LBA) ein Fehler zurückgegeben, der angibt, dass die LBA nicht lesbar ist. Wenn Ihre Compute-Instanz unerwartet neu gestartet wird, prüfen Sie nach dem Neustart der Compute-Instanz die Betriebssystem-Fehlerlogs auf Lese- oder Schreibfehler.

Die Kapazität von Hyperdisk Throughput und Hyperdisk Extreme wird gleichzeitig auf Persistent Disk-Kontingente angerechnet.

Wenn Sie Hyperdisk Durchsatz- oder Hyperdisk Extrem-Laufwerke erstellen, wird die Laufwerkskapazität gleichzeitig auf zwei separate Kontingente angerechnet: das spezifische Hyperdisk-Kontingent und ein entsprechendes Persistent Disk-Kontingent.

  • Hyperdisk Throughput Capacity (GB) (HDT-TOTAL-GB) wird auch auf Ihr Kontingent für Persistent disk standard (GB) (DISKS-TOTAL-GB) angerechnet.
  • Hyperdisk Extreme Capacity (GB) (HDX-TOTAL-GB) wird auch auf Ihr Kontingent für Persistent disk SSD (GB) (SSD-TOTAL-GB) angerechnet.

Wenn Ihr Kontingentlimit für nichtflüchtige Speicher niedriger ist als Ihr Kontingentlimit für Hyperdisk, treten QUOTA_EXCEEDED-Fehler auf. Sie können keine zusätzlichen Laufwerke erstellen, sobald das Limit für nichtflüchtige Speicher erreicht ist, auch wenn Sie noch Hyperdisk-Kontingent haben.

Um dieses Problem zu beheben, müssen Sie beide Kontingente anpassen, wenn Sie eine Erhöhung anfordern. Wenn Sie Ihr HDT-TOTAL-GB- oder HDX-TOTAL-GB-Kontingent anpassen, müssen Sie auch Ihr DISKS-TOTAL-GB- bzw. SSD-TOTAL-GB-Kontingent anpassen.

Unterbrechungen von Arbeitslasten auf A4-Instanzen aufgrund von Firmwareproblemen bei NVIDIA B200-GPUs

NVIDIA hat zwei Firmwareprobleme für B200-GPUs identifiziert, die von A4-Instanzen verwendet werden und zu Unterbrechungen von Arbeitslasten führen. Wenn Sie Unterbrechungen von Arbeitslasten auf A4-Instanzen feststellen, prüfen Sie, ob einer der folgenden Punkte zutrifft:

Setzen Sie Ihre GPUs zurück, um dieses Problem zu beheben. Um das Problem zu vermeiden, sollten Sie die GPUs auf A4-Instanzen mindestens alle 60 Tage zurücksetzen.

Mögliche Hostfehler beim Erstellen von C4-Instanzen auf Knoten für einzelne Mandanten

Bei Instanzen des Maschinentyps C4, die auf Knoten für einzelne Mandanten ausgeführt werden, kann es aufgrund von Hostfehlern oder Fehlern bei der Instanzerstellung zu unerwarteten Instanzbeendigungen kommen.

Um dieses Problem zu beheben, hat Google die maximale Anzahl von C4-Instanzen pro Knoten mit Einzelmandant auf 26 begrenzt.

Serielle Konsole ist für C4- und C4D-Bare-Metal-Instanzen schreibgeschützt

Für Bare-Metal-Instanzen vom Typ C4 oder C4D kann der interaktive Zugriff auf die serielle Konsole nicht aktiviert werden. Die serielle Konsole hat nur Lesezugriff.

Problemumgehung

Wenn Sie Befehle interaktiv ausführen möchten, können Sie nach dem Start der Instanz eine SSH-Verbindung zur Instanz herstellen. Informationen zur Verwendung von SSH mit Compute Engine-Instanzen finden Sie unter Informationen zu SSH-Verbindungen.

Das Abbrechen von Jobs in HPC-Clustern mit 32 Knoten oder mehr überschreitet das Zeitlimit.

Bei großen Jobs in Clustern mit 32 Knoten oder mehr kann die Zeit, die zum Abbrechen eines Jobs benötigt wird, den Standardwert von UnkillableStepTimeout (300 Sekunden) überschreiten. Das Überschreiten dieses Wertes führt dazu, dass die betroffenen Knoten für zukünftige Jobs nicht mehr verwendet werden können.

Verwenden Sie eine der folgenden Methoden, um dieses Problem zu beheben:

  • Aktualisieren Sie das Cluster-Toolkit auf Release 1.65.0 oder höher. Stellen Sie den Cluster dann mit dem folgenden Befehl neu bereit:

    gcluster deploy -w --force BLUEPRINT_NAME.yaml

  • Wenn Sie das Cluster Toolkit nicht aktualisieren oder den Cluster nicht neu bereitstellen können, können Sie den Parameter UnkillableStepTimeout manuell ändern. Führen Sie dazu die folgenden Schritte aus:

    1. Stellen Sie mit SSH eine Verbindung zum Hauptcontrollerknoten Ihres Clusters her.

      gcloud compute ssh --project PROJECT_ID --zone ZONE DEPLOYMENT_NAME-controller

      Den genauen Namen und die IP-Adresse des Hauptcontrollerknotens finden Sie in der Google Cloud Console auf der Seite VM-Instanzen.

    2. Erstellen Sie eine Sicherungskopie der aktuellen cloud.conf-Datei. Diese Datei befindet sich normalerweise in /etc/slurm/.

      sudo cp /etc/slurm/cloud.conf /etc/slurm/cloud.conf.backup-$(date +%Y%m%d)

    3. Öffnen Sie die Datei /etc/slurm/cloud.conf mit einem Texteditor und sudo-Berechtigungen.

    4. Fügen Sie die Zeile mit UnkillableStepTimeout hinzu oder ändern Sie sie. Legen Sie das Zeitlimit beispielsweise so auf 900 Sekunden (15 Minuten) fest:

      UnkillableStepTimeout=900

    5. Speichern Sie die Datei.

    6. Verwenden Sie den Befehl sudo scontrol reconfigure, um die neue Einstellung auf den gesamten Cluster anzuwenden, ohne dass ein vollständiger Neustart erforderlich ist.

Fehlerbehebung prüfen

Sie können prüfen, ob sich die Einstellung geändert hat, indem Sie den folgenden Befehl ausführen:

   scontrol show config | grep UnkillableStepTimeout

Die Ausgabe sollte den neuen Wert widerspiegeln, den Sie festgelegt haben, z. B.: UnkillableStepTimeout = 900.

Behoben: Das Ändern der IOPS oder des Durchsatzes auf einem primären Laufwerk für die asynchrone Replikation mit dem Befehl gcloud compute disks update führt zu einem falschen Fehler.

Das folgende Problem wurde am 1. Juni 2025 behoben.

Wenn Sie den Befehl gcloud compute disks update verwenden, um die IOPS und den Durchsatz auf einem primären Asynchronous Replication-Laufwerk zu ändern, zeigt die gcloud CLI eine Fehlermeldung an, auch wenn die Aktualisierung erfolgreich war.

Um genau zu prüfen, ob ein Update erfolgreich war, sehen Sie sich die Festplattenattribute mit der gcloud CLI oder der Google Cloud -Konsole an, um die neuen IOPS- und Durchsatzwerte zu sehen. Weitere Informationen finden Sie unter Bereitgestellte Leistungseinstellungen für Hyperdisk aufrufen.

Der Metadatenserver zeigt möglicherweise alte physicalHost-Compute-Instanzmetadaten an.

Nach einem Hostfehler, bei dem eine Compute-Instanz auf einen neuen Host verschoben wird, kann es vorkommen, dass beim Abfragen des Metadatenservers die physicalHost-Metadaten des vorherigen Hosts der Instanz angezeigt werden.

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

Lange baseInstanceName-Werte in verwalteten Instanzgruppen (MIGs) können zu Konflikten bei Festplattennamen führen.

In einer MIG können Konflikte bei Laufwerksnamen auftreten, wenn in der Instanzvorlage angegeben ist, dass beim Erstellen einer Compute-Instanz Laufwerke erstellt werden sollen, und der Wert baseInstanceName mehr als 54 Zeichen umfasst. Das liegt daran, dass Compute Engine Laufwerknamen mit dem Instanznamen als Präfix generiert.

Wenn beim Generieren von Laufwerksnamen der resultierende Name das Limit für Ressourcennamen von 63 Zeichen überschreitet, werden die zusätzlichen Zeichen am Ende des Instanznamens von Compute Engine abgeschnitten. Diese Kürzung kann dazu führen, dass für Instanzen mit ähnlichen Namensmustern identische Laufwerknamen erstellt werden. In diesem Fall wird versucht, das vorhandene Laufwerk an die neue Instanz anzuhängen. Wenn das Laufwerk bereits an eine andere Compute-Instanz angehängt ist, schlägt die Erstellung der neuen Instanz fehl. Wenn das Laufwerk nicht angehängt ist oder sich im Multi-Writer-Modus befindet, wird es von der neuen Instanz angehängt, was möglicherweise zu Datenbeschädigung führt.

Um Konflikte bei Laufwerknamen zu vermeiden, sollte der Wert baseInstanceName maximal 54 Zeichen lang sein.

Das Erstellen von Reservierungen oder zukünftigen Reservierungsanfragen mit einer Instanzvorlage, die einen A2-, C3- oder G2-Maschinentyp angibt, führt zu Problemen

Wenn Sie eine Instanzvorlage verwenden, die einen A2-, C3- oder G2-Maschinentyp angibt, um eine Reservierung zu erstellen oder eine vorausschauende Reservierungsanfrage zu erstellen und zur Überprüfung einzureichen, treten Probleme auf. Konkret kann Folgendes passieren:

  • Das Erstellen der Reservierung kann fehlschlagen. Wenn die Anfrage erfolgreich ist, gilt einer der folgenden Punkte:

    • Wenn Sie eine automatisch genutzte Reservierung erstellt haben (Standardeinstellung), wird die Reservierung nicht durch das Erstellen von Compute-Instanzen mit übereinstimmenden Attributen genutzt.

    • Wenn Sie eine bestimmte Reservierung erstellt haben, schlägt das Erstellen von Compute-Instanzen, die speziell auf die Reservierung ausgerichtet sind, fehl.

  • Das Erstellen der vorausschauenden Reservierungsanfrage ist erfolgreich. Wenn Sie sie jedoch zur Überprüfung einreichen, wird Ihr Antrag von Google Cloud abgelehnt.

Sie können die Instanzvorlage, die zum Erstellen einer Reservierung oder einer zukünftigen Reservierungsanfrage verwendet wird, nicht ersetzen oder die Instanzattribute der Vorlage überschreiben. Wenn Sie Ressourcen für A2-, C3- oder G2-Maschinentypen reservieren möchten, führen Sie stattdessen einen der folgenden Schritte aus:

Einschränkungen bei Verwendung von -lssd-Maschinentypen mit Google Kubernetes Engine

Wenn Sie die Google Kubernetes Engine API verwenden, muss der Knotenpool, den Sie mit lokalen SSD-Laufwerken bereitstellen, die gleiche Anzahl an lokalen SSD-Laufwerken wie der ausgewählte C4-, C3- oder C3D-Maschinentyp haben. Wenn Sie beispielsweise eine Compute-Instanz mit dem Maschinentyp c3-standard-8-lssd erstellen möchten, müssen Sie zwei lokale SSD-Laufwerke verwenden. Wenn Sie den Maschinentyp c3d-standard-8-lssd verwenden, ist nur ein Laufwerk erforderlich. Wenn die Laufwerksnummer nicht übereinstimmt, erhalten Sie einen Fehler bei der lokalen SSD-Fehlkonfiguration von der Compute Engine-Steuerungsebene. Unter Maschinentypen, bei denen automatisch lokale SSD-Laufwerke angehängt werden finden Sie Informationen zur Auswahl der richtigen Anzahl lokaler SSD-Laufwerke basierend auf dem lssd-Maschinentyp.

Wenn Sie die Google Kubernetes Engine-Konsole Google Cloud verwenden, um einen Cluster oder Knotenpool zu erstellen, schlägt die Knotenerstellung fehl oder lokale SSDs werden nicht als sitzungsspezifischer Speicher erkannt, wenn Sie einen der folgenden Maschinentypen verwenden:

  • c4-standard-*-lssd
  • c4-highmem-*-lssd
  • c3-standard-*-lssd
  • c3d-standard-*-lssd

Schwankungen des TCP-Durchsatzes für einzelne Abläufe auf C3D-Instanzen

Bei C3D-Instanzen mit mehr als 30 vCPUs kann es zu Schwankungen des TCP-Durchsatzes für einzelne Abläufe kommen und ist gelegentlich auf 20 bis 25 Gbit/s beschränkt. Um höhere Raten zu erreichen, verwenden Sie mehrere TCP-Flows.

Der Messwert zur Beobachtbarkeit der CPU-Auslastung ist für Compute-Instanzen, die einen Thread pro Kern verwenden, nicht korrekt.

Wenn die CPU Ihrer Compute-Instanz einen Thread pro Kern verwendet, skaliert der Cloud Monitoring-Messwert zur CPU-Auslastung auf dem Tab Beobachtbarkeit* der Seite VM-Instanzen in der Compute Engine-Konsole Google Cloud nur auf 50%. Zwei Threads pro Kern sind für die meisten Maschinentypen die Standardeinstellung. Weitere Informationen finden Sie unter Anzahl der Threads pro Kern festlegen.

Wenn Sie die CPU-Auslastung Ihrer Compute-Instanz normalisiert auf 100 % ansehen möchten, rufen Sie stattdessen die CPU-Auslastung im Metrics Explorer auf. Weitere Informationen finden Sie unter Diagramme mit dem Metrics Explorer erstellen.

SSH im Browser-Verbindungen in derGoogle Cloud Console können fehlschlagen, wenn Sie benutzerdefinierte Firewallregeln verwenden

Wenn Sie den SSH-Zugriff auf Ihre Compute-Instanzen mit benutzerdefinierten Firewallregeln steuern, können Sie die Funktion SSH im Browser möglicherweise nicht verwenden.

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

Temporäre Namen für Laufwerke

Während Compute-Instanz-Updates, die mit dem Befehl gcloud compute instances update oder der API-Methode instances.update initiiert werden, kann Compute Engine den Namen der Laufwerke Ihrer Compute-Instanz vorübergehend ändern. Dazu werden dem ursprünglichen Namen die folgenden Suffixe hinzugefügt:

  • -temp
  • -old
  • -new

Compute Engine entfernt das Suffix und stellt die ursprünglichen Laufwerknamen nach Abschluss der Aktualisierung wieder her.

Höhere Latenz für einige nichtflüchtige Speicher aufgrund von Größenänderung des Laufwerks

In einigen Fällen kann die Größe von großen nichtflüchtigen Speichern (ca. 3 TB) oder die E/A-Leistung des Laufwerks beeinträchtigt werden. Wenn Sie von diesem Problem betroffen sind, kann es bei Ihren nichtflüchtigen Speichern zu einer erhöhten Latenz während des Größenänderungsvorgangs kommen. Dieses Problem kann sich auf nichtflüchtige Speicher eines beliebigen Typs auswirken.

Ihre automatisierten Prozesse können fehlschlagen, wenn sie API-Antwortdaten zu Ihren ressourcenbasierten Zusicherungskontingenten verwenden

Ihre automatisierten Prozesse, die API-Antwortdaten zu Ihren ressourcenbasierten Zusicherungskontingenten für Compute Engine verbrauchen und verwenden, können fehlschlagen, wenn Folgendes eintritt. Ihre automatisierten Prozesse können Code-, Geschäftslogik- oder Datenbankfelder enthalten, die die API-Antworten verwenden oder speichern.

  1. Die Antwortdaten stammen aus einer der folgenden Compute Engine API-Methoden:

  2. Sie definieren ein int anstelle einer number, um das Feld für das Ressourcenkontingentlimit in den API-Antworttexten zu definieren. Sie finden das Feld für jede Methode auf folgende Weise:

  3. Sie haben ein unbegrenztes Standardkontingent für jede Ihrer Compute Engine-SKUs.

    Weitere Informationen zu Kontingenten für Zusicherungen und zugesicherte SKUs finden Sie unter Kontingente für Zusicherungen und zugesicherte Ressourcen.

Ursache

Wenn Sie ein begrenztes Kontingent haben und das Feld items[].quotas[].limit oder quotas[].limit als int-Typ definieren, fallen die API-Antwortdaten für Ihre Kontingentlimits möglicherweise weiterhin in den Bereich des int-Typs und Ihr automatisierter Prozess wird möglicherweise nicht unterbrochen. Wenn das Standardkontingentlimit jedoch unbegrenzt ist, gibt die Compute Engine API einen Wert für das Feld limit zurück, der außerhalb des durch den Typ int definierten Bereichs liegt. Der automatisierte Prozess kann den von der API-Methode zurückgegebenen Wert nicht verarbeiten und schlägt daher fehl.

Problemumgehung

Sie können dieses Problem umgehen und Ihre automatisierten Berichte weiterhin so generieren:

  • Empfohlen:Folgen Sie der Referenzdokumentation zur Compute Engine API und verwenden Sie die richtigen Datentypen für die API-Methodendefinitionen. Definieren Sie insbesondere den Typ number, um die Felder items[].quotas[].limit und quotas[].limit für Ihre API-Methoden zu definieren.

  • Verringern Sie das Kontingentlimit auf einen Wert unter 9.223.372.036.854.775.807. Sie müssen Kontingentbeschränkungen für alle Projekte festlegen, die ressourcenbasierte Zusicherungen in allen Regionen haben. Dies kann auf eine der folgenden Arten geschehen:

Bekannte Probleme bei GPU-Instanzen

Im folgenden Abschnitt werden die bekannten Probleme für Compute Engine-GPU-Instanzen beschrieben.

Bei beschleunigungsoptimierten Maschinentypen, an die automatisch lokale SSD-Laufwerke angehängt werden, kann es Stunden dauern, bis sie beendet und neu gestartet werden.

An beschleunigungsoptimierte Maschinentypen sind automatisch GPUs angehängt. Bei den meisten beschleunigungsoptimierten Maschinentypen der A-Serie, mit Ausnahme von A2 Standard, werden automatisch lokale SSD-Laufwerke angehängt.

Beschleunigeroptimierte Maschinentypen unterstützen keine Live-Migration und Sie müssen ihre Hostwartungsrichtlinie auf TERMINATE festlegen. Es kann bis zu einer Stunde dauern, bis diese Maschinentypen nach Fehlern oder Hostfehlern beendet werden. Bei den beschleunigeroptimierten Maschinentypen, an die automatisch lokale SSD-Laufwerke angehängt werden, kann der Beendigungsprozess mehrere Stunden dauern.

Fehler bei der Erstellung und geringere Leistung bei Verwendung dynamischer NICs mit GPU-Instanzen

Dynamische NICs werden nicht für die Verwendung mit GPU-Instanzen unterstützt. Wenn Sie eine GPU-Instanz mit dynamischen NICs erstellen oder einer vorhandenen GPU-Instanz dynamische NICs hinzufügen, können die folgenden Probleme auftreten:

  • Der Vorgang schlägt mit einem Fehler wie dem folgenden fehl:

    Internal error. Please try again or contact Google Support. (Code: 'CODE')

  • Der Vorgang wird erfolgreich ausgeführt, aber die Leistung der Instanz ist geringer, z. B. ist die Netzwerkbandbreite deutlich niedriger.

Diese Probleme treten auf, weil die dynamische NIC-Konfiguration zu Fehlern führt, wenn Compute Engine versucht, die virtuellen NICs der Instanz auf physische NICs auf dem Hostserver zu verteilen.

Bekannte Probleme bei Bare-Metal-Instanzen

Dies sind die bekannten Probleme bei Bare-Metal-Instanzen der Compute Engine.

C4D-Bare-Metal-Maschinentypen unterstützen keine SUSE Linux 15 SP6-Images

Auf C4D-Bare-Metal-Instanzen kann das Betriebssystem SUSE Linux Enterprise Server (SLES) Version 15 SP6 nicht ausgeführt werden.

Problemumgehung

Verwenden Sie stattdessen SLES 15 SP5.

Hostwartungssimulation funktioniert nicht für C4-Bare-Metal-Instanzen

Die Maschinentypen c4-standard-288-metal und c4-highmem-288-metal unterstützen keine Simulation von Hostwartungsereignissen.

Problemumgehung

Verwenden Sie virtuelle Maschinen (VM)-Instanzen, die mit anderen C4-Maschinentypen erstellt wurden, um Wartungsereignisse zu simulieren.

  1. Erstellen Sie eine VM-Instanz mit einem C4-Maschinentyp, der nicht auf -metal endet.

    Konfigurieren Sie beim Erstellen der VM die C4-Instanz für Terminate, anstatt die Live-Migration bei Hostwartungsereignissen zu verwenden.

  2. Simulieren Sie ein Hostwartungsereignis für diese VM.

Während eines simulierten Hostwartungsereignisses ist das Verhalten von VMs, die für Terminate konfiguriert sind, dasselbe wie bei C4-Bare-Metal-Instanzen.

Leistung geringer als erwartet bei Z3-Bare-Metal-Instanzen unter RHEL 8

Wenn Sie Red Hat Enterprise Linux (RHEL) Version 8 mit einer Z3-Bare-Metal-Instanz verwenden, ist die Netzwerkleistung niedriger als erwartet.

Ursache

In der Linux-Kernel-Version 4.18, die von RHEL 8 verwendet wird, fehlt das Page Pool-Feature.

Problemumgehung

Verwenden Sie eine neuere Version von RHEL oder ein anderes Betriebssystem, wenn Sie mit Z3-Bare-Metal-Instanzen arbeiten.

Probleme bei der Verwendung von Dynamic Network Interfaces

In diesem Abschnitt werden bekannte Probleme bei der Verwendung mehrerer Netzwerkschnittstellen und dynamischer Netzwerkschnittstellen beschrieben.

Verworfene Pakete bei Verwendung dynamischer NICs mit Alias-IP-Bereichen, Protokollweiterleitung oder Passthrough-Network-Load-Balancern

Der Gast-Agent fügt in den folgenden Szenarien automatisch lokale Routen für vNICs, aber nicht für dynamische NICs hinzu:

  • Wenn Sie einen Alias-IP-Bereich konfigurieren, erstellt der Gast-Agent eine lokale Route für den Alias-IP-Bereich.
  • Wenn Sie eine Zielinstanz erstellen, die auf eine Compute-Instanz für die Protokollweiterleitung verweist, erstellt der Gast-Agent eine lokale Route für die zugehörige IP-Adresse der Weiterleitungsregel.
  • Wenn Sie einem Passthrough Network Load Balancer ein Backend hinzufügen, erstellt der Gast-Agent eine lokale Route für die zugehörige IP-Adresse der Weiterleitungsregel.

Da die lokalen Routen nicht für dynamische NICs hinzugefügt werden, kann es bei der dynamischen NIC zu verworfenen Paketen kommen.

So beheben Sie das Problem:

  1. Stellen Sie eine SSH-Verbindung zur Instanz her.

  2. Wenn Sie einen Alias-IP-Bereich konfigurieren, gehen Sie so vor. Ansonsten können Sie diesen Schritt überspringen.

    1. Achten Sie in /etc/default/instance_configs.cfg darauf, dass die Einstellung ip_aliases auf true festgelegt ist.

    2. Wenn die Einstellung „ip_aliases“ auf false festgelegt ist, ändern Sie die Datei in true und starten Sie den Gast-Agenten neu:

      systemctl restart google-guest-agent

  3. Konfigurieren Sie eine lokale Route für den Alias-IP-Bereich oder die IP-Adresse der Weiterleitungsregel mit dem folgenden Befehl:

    ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66

    Ersetzen Sie Folgendes:

    • IP_ADDRESS: der Alias-IP-Bereich oder die IP-Adresse der Weiterleitungsregel, für die Sie eine lokale Route hinzufügen möchten.
    • DYNAMIC_NIC_DEVICE_NAME: der Gerätename der dynamischen NIC, für die Sie eine lokale Route hinzufügen möchten. Beispiel: a-gcp.ens4.3.

Probleme bei der Installation und Verwaltung dynamischer NICs in Gast-Agent-Versionen 20250901.00 bis 20251120.01

Wenn Sie die automatische Verwaltung dynamischer NICs konfigurieren und auf Ihrer Instanz der Gast-Agent in einer Version zwischen 20250901.00 und 20251120.01 ausgeführt wird, können die folgenden Probleme auftreten:

  • Der Gast-Agent kann nicht installiert werden und dynamische NICs im Gastbetriebssystem Ihrer Instanz nicht verwalten.

    Wenn Sie im Gastbetriebssystem Befehle ausführen, die auf dynamische NICs verweisen, erhalten Sie möglicherweise einen Fehler, der Cannot find device enthält.

  • Wenn Sie mehrere dynamische NICs löschen, ist der Metadatenserver nicht mehr zugänglich.

Ursache

Ab Version 20250901.00 wurde der Gast-Agent auf eine neue, auf Plug-ins basierende Architektur migriert, um die Modularität zu verbessern. Die automatische Installation und Verwaltung dynamischer NICs wurde in der neuen Architektur anfangs nicht unterstützt.

Lösung

Aktualisieren Sie Ihre Instanz auf die Gast-Agent-Version 20251205.00 oder höher, um diese Probleme zu beheben:

  1. Informationen zum Aktualisieren des Gast-Agents auf die neueste Version finden Sie unter Gastumgebung aktualisieren.
  2. Informationen zum Bestätigen der Gast-Agent-Version, die auf Ihrer Instanz ausgeführt wird, finden Sie unter Installierte Pakete nach Betriebssystemversion aufrufen.

Falls erforderlich, können Sie diese Probleme für Instanzen, auf denen die Gast-Agent-Versionen 20250901.00 bis 20251120.01 ausgeführt werden, vorübergehend umgehen, indem Sie der Anleitung unter Abwärtskompatibilität folgen, um zur vorherigen Gast-Agent-Architektur zurückzukehren.

Das Abfangen von Paketen kann dazu führen, dass Pakete aufgrund fehlender VLAN-Tags in den Ethernet-Headern gelöscht werden.

Das Abfangen von Paketen bei Verwendung von Dynamic NIC kann zu Paketverlusten führen. Paketverluste können auftreten, wenn die Pipeline vorzeitig beendet wird. Das Problem betrifft sowohl sitzungsbasierte als auch nicht sitzungsbasierte Modi.

Ursache

Verworfene Pakete treten beim Abfangen von Paketen auf, wenn die Pipeline frühzeitig beendet wird (Ingress-Abfangen und Egress-Wiedereinfügen). Durch die vorzeitige Beendigung fehlt die VLAN-ID im Ethernet-Header des eingehenden Pakets. Da das Egress-Paket vom geänderten Ingress-Paket abgeleitet wird, fehlt auch dem Egress-Paket die VLAN-ID. Dies führt zu einer falschen Auswahl des Endpunktindex und zu nachfolgenden Paketverlusten.

Problemumgehung

Verwenden Sie keine Google Cloud Funktionen, die auf dem Abfangen von Paketen basieren, z. B. Firewall-Endpunkte.

Bekannte Probleme bei Linux-Compute-Instanzen

Dies sind die bekannten Probleme bei Linux-Compute-Instanzen.

Fehler beim Paket-Upgrade unter Rocky Linux 9.7

dnf update schlägt bei Rocky Linux Accelerator Optimized-Images der Version v20251113 oder früher (z. B. rocky-linux-9-optimized-gcp-nvidia-latest-v20251113) aufgrund eines Paketabhängigkeitskonflikts fehl. Möglicherweise wird ein Fehler wie der folgende angezeigt:

[root@rockylinux9 ~]# dnf update
CIQ SIG/Cloud Next for Rocky Linux 9 37 MB/s | 49 MB 00:01
CIQ SIG/Cloud Next Nonfree for Rocky Linux 9 4.4 MB/s | 1.5 MB 00:00
NVIDIA DOCA 2.10.0 packages for EL 9.5 239 kB/s | 160 kB 00:00
Google Compute Engine 38 kB/s | 8.2 kB 00:00
Google Cloud SDK 59 MB/s | 154 MB 00:02
Rocky Linux 9 - BaseOS 24 MB/s | 6.3 MB 00:00
Rocky Linux 9 - AppStream 36 MB/s | 11 MB 00:00
Rocky Linux 9 - Extras 124 kB/s | 16 kB 00:00
Error:
 Problem 1: package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1(HNS_1.0)(64bit), but none of the providers can be installed
  - package perftest-25.04.0.0.84-1.el9.x86_64 from baseos requires libhns.so.1()(64bit), but none of the providers can be installed
  - cannot install both libibverbs-51.0-3.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-51.0-5.el9_5.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-2.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-3.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-4.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-54.0-5.el9_6.cld_next.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-57.0-3.el9_7_ciq.x86_64 from ciq-sigcloud-next and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install both libibverbs-57.0-2.el9.x86_64 from baseos and libibverbs-2501mlnx56-1.2501060.x86_64 from @System
  - cannot install the best update candidate for package perftest-25.01.0-0.70.g759a5c5.2501060.x86_64
  - cannot install the best update candidate for package libibverbs-2501mlnx56-1.2501060.x86_64
 Problem 2: package ucx-ib-mlx5-1.18.0-1.2501060.x86_64 from @System requires ucx(x86-64) = 1.18.0-1.2501060, but none of the providers can be installed
  - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from @System
  - cannot install both ucx-1.18.1-1.el9.x86_64 from appstream and ucx-1.18.0-1.2501060.x86_64 from doca
  - cannot install the best update candidate for package ucx-ib-mlx5-1.18.0-1.2501060.x86_64
  - cannot install the best update candidate for package ucx-1.18.0-1.2501060.x86_64
...
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

Ursache

Zwischen DOCA OFED-Versionen vor 3.20 und Rocky Linux 9.7 besteht ein Konflikt bei der Userspace-Paketversion. Rocky Linux 9.7 enthält die Pakete ucx und perftest, die eine neuere Version als die entsprechenden Pakete im DOCA OFED-Repository sind. Diese Versionsabweichung führt dazu, dass dnf update mit Fehlern bei der Abhängigkeitsauflösung fehlschlägt.

Lösung

Bevor Sie ein vollständiges Systemupgrade durchführen, aktualisieren Sie das DOCA-Repository-Paket:

sudo dnf update doca-repo
sudo dnf update

In Rocky Linux Accelerator Optimized-Images, die im Dezember 2025 erstellt wurden (z. B. rocky-linux-9-optimized-gcp-nvidia-latest-v20251215), ist das aktualisierte doca-repo-Paket bereits enthalten. Dieses Upgrade-Problem tritt daher bei diesen Builds oder höher nicht auf.

OS Login wird auf SLES 16 nicht unterstützt

Ein SSH-Konfigurationsproblem in SUSE Linux Enterprise Server (SLES) 16 verhindert die Verwendung des Google Cloud Features OSLogin. Metadatenverwaltete SSH-Verbindungen sind jedoch nicht betroffen und funktionieren weiterhin.

Unterstützte URL-Formate für Startskript

Wenn Ihre Compute-Instanz die Gast-Agent-Version 20251115.00 verwendet, schlägt das Abrufen eines Startscripts mit dem Metadatenschlüssel startup-script-url fehl, wenn die URL das Format https://storage.googleapis.com/ verwendet, das auf der Seite Startscripts auf Linux-VMs verwenden dokumentiert ist.

Verwenden Sie eines der folgenden unterstützten URL-Formate, um dieses Problem zu umgehen:

  • Authentifizierte URL: https://storage.cloud.google.com/BUCKET/FILE
  • gcloud CLI Cloud Storage-URI: gs://BUCKET/FILE

Auf VM-Instanzen, die Debian 11-Images vor Version v20250728 verwenden, kann apt update nicht ausgeführt werden.

Am 22. Juli 2025 hat die Debian-Community die Backports von Debian 11 (Bullseye) aus dem Haupt-Upstream von Debian entfernt. Dieses Update führt dazu, dass sudo apt update mit folgendem Fehler fehlschlägt:

The repository 'https://deb.debian.org/debian bullseye-backports Release' does
not have a Release file.

Ursache

Da die Debian-Community die Backports-Repositories aus dem Haupt-Upstream entfernt hat, gibt es keinen Verweis mehr auf bullseye-backports Release.

Lösung

Verwenden Sie die Bildversion debian-11-bullseye-v20250728 oder höher. Diese Versionen enthalten die Backports-Repositories nicht. Alternativ können Sie aktuelle Instanzen aktualisieren, indem Sie /etc/apt/sources.list ändern:

  • So aktualisieren Sie die Repository-URL und verwenden das Archiv für bullseye-backports:

    sudo sed -i 's/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/deb https:\/\/archive.debian.org\/debian bullseye-backports main/g; s/^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/deb-src https:\/\/archive.debian.org\/debian bullseye-backports main/g' /etc/apt/sources.list

  • So löschen Sie die Repository-URL und verwerfen bullseye-backports:

    sudo sed -i '/^deb https:\/\/deb.debian.org\/debian bullseye-backports main$/d; /^deb-src https:\/\/deb.debian.org\/debian bullseye-backports main$/d' /etc/apt/sources.list

Durch die Installation des ubuntu-desktop-Pakets wird die Netzwerkverbindung unterbrochen, wenn die Instanz neu gestartet wird.

Wenn Sie eine Ubuntu-Compute-Instanz nach der Installation des ubuntu-desktop-Pakets neu starten, sind die Netzwerkschnittstellen möglicherweise nicht richtig konfiguriert.

Ursache

Das Paket ubuntu-deskop zieht ubuntu-settings als Abhängigkeit ab, wodurch NetworkManager als Standard-„Renderer“ für Netplan festgelegt wird. Genauer gesagt wird eine neue YAML-Konfiguration für netplan in /usr/lib/netplan/00-network-manager-all.yaml eingefügt, die Folgendes enthält:

network:
  version: 2
  renderer: NetworkManager

Diese Konfiguration steht in Konflikt mit der networkd-basierten Vorabkonfiguration mit cloud-init.

Wiederherstellung

Wenn die Compute-Instanz neu gestartet wurde und nicht zugänglich ist, gehen Sie so vor:

  1. Folgen Sie der Anleitung zum Wiederherstellen einer Compute-Instanz.

  2. Nachdem Sie die Partition des Linux-Dateisystems der nicht zugänglichen Compute-Instanz bereitgestellt haben, führen Sie den folgenden Befehl aus und ersetzen Sie /rescue durch Ihren Bereitstellungspunkt:

    echo -e 'network:\n  version: 2\n  renderer: networkd' | sudo tee /rescue/etc/netplan/99-gce-renderer.yaml

  3. Die nicht zugängliche Compute-Instanz weiterhin neu starten

Bei Compute-Instanzen, die die Ubuntu-Betriebssystemversion v20250530 verwenden, wird ein falscher FQDN angezeigt.

Möglicherweise wird ein falscher voll qualifizierter Domainname (Fully Qualified Domain Name, FQDN) mit dem Suffix .local angezeigt, wenn Sie eine der folgenden Aktionen ausführen:

  • Aktualisieren Sie auf Version 20250328.00 des google-compute-engine-Pakets.
  • Starten Sie Compute-Instanzen mit einem beliebigen von Canonical angebotenen Ubuntu-Image mit dem Versionssuffix v20250530.

Beispiel: projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530.

Wenn dieses Problem auftritt, sehen Sie möglicherweise einen FQDN wie den folgenden:

   [root@ubuntu2204 ~]# apt list --installed | grep google
   ...
   google-compute-engine/noble-updates,now 20250328.00-0ubuntu2~24.04.0 all [installed]
   ...

   [root@ubuntu2204 ~]# curl "http://metadata.google.internal/computeMetadata/v1/instance/image" -H "Metadata-Flavor: Google"
   projects/ubuntu-os-cloud/global/images/ubuntu-2204-jammy-v20250530

   [root@ubuntu2204 ~]# hostname -f
   ubuntu2204.local

Ursache

Auf allen Ubuntu-Images mit der Version v20250530 wird durch die Paketversion guest-config 20250328.00 aufgrund der Einführung einer neuen Konfigurationsdatei local dem Suchpfad hinzugefügt: https://github.com/GoogleCloudPlatform/guest-configs/blob/20250328.00/src/etc/systemd/resolved.conf.d/gce-resolved.conf

   [root@ubuntu2204 ~]# cat /etc/resolv.conf
   # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
   # Do not edit.
   ...

   nameserver 127.0.0.53
   options edns0 trust-ad
   search local ... google.internal

Das Vorhandensein dieses local-Eintrags im Suchpfad in der Datei /etc/resolv.conf führt dazu, dass dem Hostnamen ein .local-Element angehängt wird, wenn ein FQDN angefordert wird.

Beachten Sie, dass Version 20250501 von guest-configs das Problem bereits behebt. Canonical hat die Korrektur jedoch noch nicht in seine Images aufgenommen.

Problemumgehung

  1. Ändern Sie die Konfigurationsdatei für die Namensauflösung im Netzwerk /etc/systemd/resolved.conf.d/gce-resolved.conf, indem Sie Domains=local in Domains=~local ändern.
  2. Führen Sie den folgenden Befehl aus, um den Dienst „systemd-resolved“ neu zu starten: systemctl restart systemd-resolved
  3. Prüfen Sie, ob local aus dem Suchpfad in /etc/resolv.conf entfernt wurde.

  4. Bestätigen Sie den FQDN mit dem Befehl hostname -f.

    [root@ubuntu2204 ~]# hostname -f
ubuntu2204.us-central1-a.c.my-project.internal

mkfs.ext4 fehlt in openSUSE-Images

In der aktuellen v20250724-Version von openSUSE-Images (ab opensuse-leap-15-6-v20250724-x86-64) vom August 2025 fehlt das Paket e2fsprogs, das Dienstprogramme zum Verwalten von Dateisystemen enthält. Ein häufiges Symptom dieses Problems ist, dass beim Versuch, den Befehl mkfs.ext4 zu verwenden, eine Fehlermeldung wie command not found angezeigt wird.

Problemumgehung

Wenn dieses Problem auftritt, installieren Sie das fehlende Paket manuell mit dem openSUSE-Paketmanager zypper.

# Update the package index
user@opensuse:~> sudo zypper refresh

# Install the e2fsprogs package
user@opensuse:~> sudo zypper install e2fsprogs

# Verify the installation
user@opensuse:~> which mkfs.ext4

SUSE Enterprise-Compute-Instanzen können nach dem Ändern des Maschinentyps nicht mehr gestartet werden

Nachdem Sie den Maschinentyp für eine Compute-Instanz geändert haben, auf der SUSE Enterprise Linux ausgeführt wird, kann es sein, dass die Instanz nicht gestartet wird. In der seriellen Konsole wird dann der folgende Fehler angezeigt:

            Starting [0;1;39mdracut initqueue hook[0m...
   [  136.146065] dracut-initqueue[377]: Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks:
   [  136.164820] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fD3E2-0CEB.sh: "[ -e "/dev/disk/by-uuid/D3E2-0CEB" ]"
   [  136.188732] dracut-initqueue[377]: Warning: /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2fe7b218a9-449d-4477-8200-a7bb61a9ff4d.sh: "if ! grep -q After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then
   [  136.220738] dracut-initqueue[377]:     [ -e "/dev/disk/by-uuid/e7b218a9-449d-4477-8200-a7bb61a9ff4d" ]
   [  136.240713] dracut-initqueue[377]: fi"

Ursache

SUSE erstellt seine Cloud-Images mit einem vielseitigen initramfs (initial RAM-Dateisystem), das verschiedene Instanztypen unterstützt. Dies wird durch die Verwendung der --no-hostonly --no-hostonly-cmdline -o multipath-Flags bei der ersten Bilderstellung erreicht. Wenn jedoch ein neuer Kernel installiert oder die initramfs neu generiert wird (was bei Systemupdates geschieht), werden diese Flags standardmäßig ausgelassen. Dies führt zu einem kleineren initramfs, das speziell auf die Hardware des aktuellen Systems zugeschnitten ist. Möglicherweise werden Treiber für andere Instanztypen ausgeschlossen.

C3-Instanzen verwenden beispielsweise NVMe-Laufwerke, für die bestimmte Module in initramfs enthalten sein müssen. Wenn ein System mit einem initramfs, dem diese NVMe-Module fehlen, zu einer C3-Instanz migriert wird, schlägt der Bootvorgang fehl. Dieses Problem kann auch andere Instanztypen mit besonderen Hardwareanforderungen betreffen.

Problemumgehung

Bevor Sie den Maschinentyp ändern, generieren Sie die initramfs mit allen Treibern neu:

dracut --force --no-hostonly

Wenn das System bereits von dem Problem betroffen ist, erstellen Sie eine temporäre Compute-Instanz zur Fehlerbehebung. Verwenden Sie den Befehl chroot, um auf das Bootlaufwerk der betroffenen Instanz zuzugreifen, und generieren Sie dann die initramfs mit dem folgenden Befehl neu:

dracut -f --no-hostonly

Niedrigere IOPS-Leistung für lokale SSDs auf Z3-Instanzen mit SUSE 12-Images

Bei Z3-Compute-Instanzen, die SLES 12-Images (SUSE Linux Enterprise Server) verwenden, ist die Leistung für IOPS auf lokalen SSD-Festplatten deutlich geringer als erwartet.

Ursache

Dies ist ein Problem in der SLES 12-Codebasis.

Problemumgehung

Ein Patch von SUSE zur Behebung dieses Problems ist nicht verfügbar oder geplant. Verwenden Sie stattdessen das Betriebssystem SLES 15.

RHEL 7- und CentOS-Compute-Instanzen verlieren nach dem Neustart den Netzwerkzugriff

Wenn Ihre CentOS- oder RHEL 7-Compute-Instanzen mehrere Netzwerkschnittstellenkarten (NICs) haben und eine dieser NICs nicht die VirtIO-Schnittstelle verwendet, kann der Netzwerkzugriff beim Neustart verloren gehen. Das liegt daran, dass RHEL das Deaktivieren von prädiktiven Netzwerkschnittstellennamen nicht unterstützt, wenn mindestens eine NIC nicht die VirtIO-Schnittstelle verwendet.

Lösung

Die Netzwerkverbindung kann wiederhergestellt werden, indem Sie die Compute-Instanz beenden und starten, bis das Problem behoben ist. So können Sie verhindern, dass der Verlust der Netzwerkverbindung wieder auftritt:

  1. Bearbeiten Sie die Datei /etc/default/grub und entfernen Sie die Kernelparameter net.ifnames=0 und biosdevname=0.

  2. Generieren Sie die GRUB-Konfiguration neu.

  3. Starten Sie die Compute-Instanz neu.

Signatur „repomd.xml“ konnte nicht überprüft werden

Auf Red Hat Enterprise Linux- (RHEL)- oder CentOS 7-basierten Systemen kann der folgende Fehler auftreten, wenn Sie versuchen, Software mit yum zu installieren oder zu aktualisieren. Dieser Fehler zeigt an, dass Sie einen abgelaufenen oder falschen GPG-Schlüssel für das Repository haben.

Beispiellog: 

[root@centos7 ~]# yum update




...



google-cloud-sdk/signature                                                                  | 1.4 kB  00:00:01 !!!
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Trying other mirror.



...



failure: repodata/repomd.xml from google-cloud-sdk: [Errno 256] No more mirrors to try.
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Lösung

Um dieses Problem zu beheben, deaktivieren Sie die GPG-Schlüsselprüfung in der yum-Repository-Konfiguration durch Festlegen von repo_gpgcheck=0. In unterstützten Compute Engine-Basis-Images befindet sich diese Einstellung möglicherweise in der Datei /etc/yum.repos.d/google-cloud.repo. Die Compute-Instanz kann jedoch unterschiedliche Repository-Konfigurationsdateien oder Automatisierungstools enthalten.

Yum-Repositories verwenden in der Regel keine GPG-Schlüssel für die Repository-Validierung. Stattdessen ist der Endpunkt https vertrauenswürdig.

Führen Sie die folgenden Schritte aus, um diese Einstellung zu finden und zu aktualisieren:

  1. Suchen Sie die Einstellung in der Datei /etc/yum.repos.d/google-cloud.repo.

    cat /etc/yum.repos.d/google-cloud.repo


[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

  2. Ändern Sie alle Zeilen mit repo_gpgcheck=1 zu repo_gpgcheck=0.

    sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo

  3. Prüfen Sie, ob die Einstellung aktualisiert wurde.

    cat /etc/yum.repos.d/google-cloud.repo

[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

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

Lösung

Ignorieren Sie die Fehlermeldung.

Bekannte Probleme bei Windows-Instanzen

  • Die Unterstützung von NVMe unter Windows mit dem Community-NVMe-Treiber befindet sich in der Betaphase. Die Leistung entspricht möglicherweise nicht der von Linux-Instanzen. Der Community-NVMe-Treiber wurde in öffentlichen Google Cloud -Images durch den Microsoft StorNVMe-Treiber ersetzt. Wir empfehlen Ihnen, den NVME-Treiber auf Compute-Instanzen zu ersetzen, die vor Mai 2022 erstellt wurden, und stattdessen den Microsoft StorNVMe-Treiber zu verwenden.
  • 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-Compute-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.
  • Der vioscsi-Treiber, der für SCSI-Laufwerke verwendet wird, setzt das Flag removable, wodurch die Laufwerke als Wechseldatenträger behandelt werden. Dies führt zu unerwarteten Zugriffsbeschränkungen in Windows für Festplatten, die Gruppenrichtlinienobjekten (GPOs) unterliegen, die auf Wechselspeicher ausgerichtet sind.

Gast-Agent kann nicht gestartet werden

Die Windows-Gast-Agent-Version 20251011.00 kann unter bestimmten Lastbedingungen nicht gestartet werden.

Ursache Beim Verpacken des Windows-Gast-Agents für Version 20251011.00 wird der Startmodus des Windows-Gast-Agents im Windows Service Manager fälschlicherweise auf auto festgelegt.

Lösung Aktualisieren Sie Ihre Instanz auf die Gast-Agent-Version 20251120.01 oder höher, um dieses Problem zu beheben.

Manuelle Problemumgehung Wenn die Installation von Version 20251120.01 nicht möglich ist, führen Sie den folgenden Befehl aus:

  • sc.exe config GCEAgent start=delayed-auto

Funktionen zur Verwaltung von Anmeldedaten funktionieren möglicherweise nicht für Windows-Instanzen mit nicht englischen Sprachnamen

Der Windows-Gast-Agent identifiziert Administratorkonten und -gruppen mithilfe von String-Abgleich. Daher funktionieren Funktionen zur Verwaltung von Anmeldedaten nur dann richtig, wenn Sie englische Namen für Nutzerkonten und Gruppen verwenden, z. B. Administrators. Wenn Sie Namen in einer anderen Sprache als Englisch verwenden, funktionieren Funktionen zur Verwaltung von Anmeldedaten wie das Generieren oder Zurücksetzen von Passwörtern möglicherweise nicht wie erwartet.

Windows Server 2016 kann auf C3D-Maschinentypen mit 180 oder mehr vCPUs nicht gestartet werden

Windows Server 2016 kann auf C3D-Maschinentypen mit 180 oder 360 vCPUs nicht gestartet werden. Wählen Sie eine der folgenden Optionen aus, um dieses Problem zu umgehen:

  • Wenn Sie Windows Server 2016 verwenden müssen, verwenden Sie einen Maschinentyp mit weniger als 180 vCPUs.
  • Wenn Sie einen C3D-Maschinentyp mit 180 oder 360 vCPUs verwenden müssen, verwenden Sie eine neuere Version von Windows Server.

Windows Server 2025 und Windows 11 24h2/25h2 – Unterstützung für Sperrung und Fortsetzung

Windows Server 2025, Windows 11 24h2 und Windows 11 25h2 können nach dem Anhalten nicht fortgesetzt werden. Bis dieses Problem behoben ist, wird die Funktion zum Anhalten und Fortsetzen für Windows Server 2025, Windows 11 24H2 und Windows 11 25H2 nicht unterstützt.

Fehler beim Messen des NTP-Zeitdrifts mit w32tm auf Windows-Instanzen

Bei Windows-Instanzen in Compute Engine, die eine VirtIO-Netzwerkschnittstelle verwenden, gibt es einen bekannten Fehler, bei dem die Messung des NTP-Drifts Fehler erzeugt, wenn der folgende Befehl verwendet wird:

w32tm /stripchart /computer:metadata.google.internal

Die Fehler sehen etwa so aus:

Tracking metadata.google.internal [169.254.169.254:123].
The current time is 11/6/2023 6:52:20 PM.
18:52:20, d:+00.0007693s o:+00.0000285s  [                  *                  ]
18:52:22, error: 0x80072733
18:52:24, d:+00.0003550s o:-00.0000754s  [                  *                  ]
18:52:26, error: 0x80072733
18:52:28, d:+00.0003728s o:-00.0000696s  [                  *                  ]
18:52:30, error: 0x80072733
18:52:32, error: 0x80072733

Dieser Fehler betrifft nur Compute Engine-Instanzen mit VirtIO-NICs. Bei Compute-Instanzen, die gVNIC-Netzwerkschnittstellen verwenden, tritt dieses Problem nicht auf.

Zur Vermeidung dieses Problems empfiehlt Google die Verwendung anderer NTP-Drift-Messtools, z. B. den Meinberg Time Server Monitor.

Nicht zugängliches Bootgerät nach dem Aktualisieren einer Compute-Instanz von der 1. oder 2. Generation auf eine Instanz der 3. Generation oder höher

Windows Server bindet das Bootlaufwerk beim ersten Start an den ursprünglichen Laufwerksschnittstellentyp. Wenn Sie eine vorhandene Compute-Instanz von einer älteren Maschinenserie (Generation 1 oder 2), die eine SCSI-Laufwerksschnittstelle verwendet, in eine neuere Maschinenserie (Generation 3 oder höher) ändern möchten, die eine NVMe-Laufwerksschnittstelle verwendet, führen Sie vor dem Herunterfahren der Compute-Instanz einen Windows-PnP-Treiber-Sysprep durch. Bei diesem Sysprep werden nur Gerätetreiber vorbereitet und es wird geprüft, ob beim nächsten Start alle Festplattenschnittstellentypen nach dem Startlaufwerk gescannt werden.

Führen Sie an einer PowerShell-Eingabeaufforderung als Administrator Folgendes aus:

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait

So ändern Sie die Maschinenserie einer Compute-Instanz:

  1. Beenden Sie die Compute-Instanz.
  2. Bearbeiten Sie die Compute-Instanz, damit sie den neuen Maschinentyp verwendet.
  3. Starten Sie die Compute-Instanz.

Wenn die neue Compute-Instanz nicht richtig startet, bearbeiten Sie die Compute-Instanz so, dass der ursprüngliche Maschinentyp verwendet wird, und starten Sie die Instanz dann neu. Mit dieser Abfolge von Schritten sollte Ihre Compute-Instanz erfolgreich ausgeführt werden. Prüfen Sie die Anforderungen für die Migration. Wiederholen Sie dann die Anleitung.

Begrenzte Anzahl von angehängten Laufwerken für Maschinenserien, die NVMe-Laufwerke verwenden

Für Compute-Instanzen, die die NVMe-Festplattenschnittstelle und ein Microsoft Windows-Betriebssystemimage verwenden, gilt ein Limit von 16 angehängten Festplatten. Dieses Limit gilt für T2A-Instanzen, alle Compute-Instanzen der dritten Generation und Compute-Instanzen der vierten Generation der N-Serie (N4, N4D, N4A). Um Fehler zu vermeiden, sollten Sie Ihren Persistent Disk- und Hyperdisk-Speicher auf maximal 16 Laufwerke pro Compute-Instanz konsolidieren. Lokaler SSD-Speicher ist von diesem Problem ausgeschlossen.

NVME-Treiber auf Compute-Instanzen ersetzen, die vor Mai 2022 erstellt wurden

Wenn Sie NVMe auf einer Compute-Instanz verwenden möchten, die Microsoft Windows verwendet, und die Instanz vor dem 1. Mai 2022 erstellt wurde, müssen Sie den vorhandenen NVMe-Treiber im Gastbetriebssystem auf die Verwendung des Microsoft StorNVMe-Treibers aktualisieren.

Sie müssen den NVMe-Treiber auf Ihrer Compute-Instanz aktualisieren, bevor Sie den Maschinentyp in eine Maschinenserie der dritten Generation oder höher ändern oder bevor Sie einen Snapshot eines Bootlaufwerks erstellen, mit dem neue Compute-Instanzen erstellt werden, die eine Maschinenserie der dritten Generation oder höher verwenden.

Verwenden Sie die folgenden Befehle, um das StorNVME-Treiberpaket zu installieren und den Community-Treiber zu entfernen, falls er im Gastbetriebssystem vorhanden ist.

googet update
googet install google-compute-engine-driver-nvme

Geringere Leistung lokaler SSDs auf C3- und C3D-Instanzen mit Microsoft Windows

Die Leistung lokaler SSDs ist für C3- und C3D-Instanzen mit Microsoft Windows begrenzt.

Die Leistung wird derzeit verbessert.

Geringere Leistung von Hyperdisk Extreme-Volumes, die an n2-standard-80-Instanzen mit Microsoft Windows angehängt sind

Compute-Instanzen, die auf dem Maschinentyp n2-standard-80 basieren und Microsoft Windows ausführen, können maximal 80.000 IOPS für alle Hyperdisk Extreme-Volumes erreichen, die an die Instanz angehängt sind.

Lösung

Wenn Sie mit N2-Instanzen unter Windows bis zu 160.000 IOPS erreichen möchten, wählen Sie einen der folgenden Maschinentypen aus:

  • n2-highmem-80
  • n2-highcpu-80
  • n2-standard-96
  • n2-highmem-96
  • n2-highcpu-96
  • n2-highmem-128
  • n2-standard-128

Schlechter Netzwerkdurchsatz bei Verwendung von gVNIC

Bei Windows Server 2022- und Windows 11-Compute-Instanzen, die die GooGet-Paketversion 1.0.0@44 oder eine frühere Version des gVNIC-Treibers verwenden, kann es bei Verwendung von Google Virtual NIC (gVNIC) zu einem schlechten Netzwerkdurchsatz kommen.

Aktualisieren Sie das gVNIC-Treiber-GooGet-Paket auf Version 1.0.0@45 oder höher, um dieses Problem zu beheben:

  1. Prüfen Sie, welche Treiberversion auf Ihrer Compute-Instanz installiert ist. Führen Sie dazu den folgenden Befehl über eine Administrator-Eingabeaufforderung oder eine PowerShell-Sitzung aus:

    googet installed

    Die Ausgabe sieht dann ungefähr so aus:

    Installed packages:
  ...
  google-compute-engine-driver-gvnic.x86_64 VERSION_NUMBER
  ...

  2. Wenn die Treiberversion google-compute-engine-driver-gvnic.x86_64 1.0.0@44 oder früher ist, aktualisieren Sie das GooGet-Paket-Repository. Führen Sie dazu den folgenden Befehl über eine Administrator-Eingabeaufforderung oder PowerShell-Sitzung:

    googet update

Große C4-, C4D- und C3D-vCPU-Maschinentypen unterstützen keine Windows-Betriebssystem-Images

C4-Maschinentypen mit mehr als 144 vCPUs und C4D- und C3D-Maschinentypen mit mehr als 180 vCPUs unterstützen keine Betriebssystem-Images von Windows Server 2012 und 2016. Größere C4-, C4D- und C3D-Maschinentypen, die Windows Server 2012- und 2016-Betriebssystem-Images verwenden, können nicht gestartet werden. Wählen Sie einen kleineren Maschinentyp aus oder verwenden Sie ein anderes Betriebssystem-Image, um dieses Problem zu umgehen.

C3D-Instanzen, die mit 360 vCPUs und Windows-Betriebssystem-Images erstellt wurden, können nicht gestartet werden. Wählen Sie einen kleineren Maschinentyp aus oder verwenden Sie ein anderes Betriebssystem-Image, um dieses Problem zu umgehen.

C4D-Instanzen, die mit mehr als 255 vCPUs und Windows 2025-Images erstellt wurden, können nicht gestartet werden. Wählen Sie einen kleineren Maschinentyp aus oder verwenden Sie ein anderes Betriebssystem-Image, um dieses Problem zu umgehen.

Allgemeiner Laufwerkfehler unter Windows Server 2016 und 2012 R2 für M3-, C3-, C3D- und C4D-Instanzen

Das Hinzufügen oder Ändern der Größe einer Hyperdisk oder eines Persistent Disk für eine laufende M3-, C3-, C3D- oder C4D-Instanz funktioniert bei bestimmten Windows-Gästen derzeit nicht wie erwartet. Windows Server 2012 R2 und Windows Server 2016 sowie die entsprechenden Windows-Client-Images reagieren nicht ordnungsgemäß auf die Befehle „Laufwerk anhängen“ und „Laufwerkgröße anpassen“.

Wenn Sie beispielsweise ein Laufwerk von einer ausgeführten M3-Instanz entfernen, wird das Laufwerk getrennt, aber das Windows-Betriebssystem erkennt nicht, dass das Laufwerk nicht mehr verfügbar ist. Nachfolgende Schreibvorgänge auf dem Laufwerk geben einen allgemeinen Fehler zurück.

Lösung

Wenn Sie M3-, C3-, C3D- oder C4D-Instanzen verwenden, die unter Windows ausgeführt werden, und Sie ein Hyperdisk- oder nichtflüchtiges Speichervolume ändern, müssen Sie die Compute-Instanz neu starten, damit die Änderungen am Laufwerk erkannt werden.