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.

Der Gast-Agent ignoriert die Option ip_forwarding in der NetworkInterfaces-Konfiguration.

Der Konfigurationsabschnitt NetworkInterfaces des Gast-Agents enthält die Option ip_forwarding. Mit dieser Option können Sie verhindern, dass der Agent Alias-IP-Adressen und IP-Weiterleitungsrouten vom Metadatenserver (MDS) installiert. Bei Gast-Agent-Versionen, die die Plug-in-basierte Architektur verwenden, einschließlich des Core-Plug-ins, ignoriert der Agent jedoch die Konfigurationsoption ip_forwarding. Der Gast-Agent installiert unabhängig von der Konfiguration Alias-IP-Adressen und IP-Weiterleitungsrouten. Weitere Informationen finden Sie in der Dokumentation zum Gast-Agent. Dieses Problem betrifft Sie, wenn Sie SAP Netweaver Pacemaker in einer Einrichtung mit einem internen Load Balancer (ILB) verwenden.

Um dieses Problem zu beheben, setzen Sie das Metadatenattribut enable-guest-agent-core-plugin auf false, wie in der Dokumentation zur Abwärtskompatibilität beschrieben.

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

In seltenen Fällen können Shielded VM-Instanzen, die vor dem 7. November 2025 mit aktiviertem Secure Boot erstellt wurden, oder Instanzen, die Software zur Datenträgervollverschlüsselung oder Secret Sealing für vTPM-PCRs verwenden, möglicherweise nicht gestartet werden. Dies kann durch eine falsche Reihenfolge von Updates verursacht werden (z. B. Aktualisierung von Shim ohne die richtigen 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.

An C4-, C4A-, C4D-, C4N- und H4D-Instanzen angehängte lokale SSD-Laufwerke erfassen bei einem Stromausfall möglicherweise nicht alle Schreibvorgänge

Wenn Compute Engine nach einem Stromausfall auf einem Hostserver die Daten auf den lokalen SSD-Laufwerken wiederherstellen kann, wird eine auf diesem Hostserver ausgeführte Compute-Instanz mit allen angehängten Laufwerken neu gestartet. Die Daten enthalten alle Schreibvorgänge, die vor dem Hostfehler abgeschlossen wurden.

Bei C4-, C4A-, C4D-, C4N- 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 von einer betroffenen logischen Blockadresse (LBA) ein Fehler zurückgegeben, der angibt, dass die LBA nicht lesbar ist. Wenn Ihre Compute-Instanz unerwartet neu gestartet wird, prüfen Sie die Betriebssystem-Fehlerlogs nach dem Neustart der Compute-Instanz auf Lese- oder Schreibfehler.

Hyperdisk Throughput- und Hyperdisk Extreme-Kapazität verbrauchen gleichzeitig Persistent Disk-Kontingente

Wenn Sie Hyperdisk Throughput- oder Hyperdisk Extreme-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 Persistent disk standard (GB)-Kontingent (DISKS-TOTAL-GB) angerechnet.
  • Hyperdisk Extreme Capacity (GB) (HDX-TOTAL-GB) wird auch auf Ihr Persistent disk SSD (GB)-Kontingent (SSD-TOTAL-GB) angerechnet.

Wenn Ihr Kontingentlimit für Persistent Disk niedriger ist als Ihr Kontingentlimit für Hyperdisk, treten QUOTA_EXCEEDED-Fehler auf. Sie können keine zusätzlichen Laufwerke erstellen, wenn das Persistent Disk-Limit erreicht ist, auch wenn Sie noch Hyperdisk-Kontingent übrig 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.

Arbeitslastunterbrechungen auf A4-Instanzen aufgrund von Firmwareproblemen bei NVIDIA B200-GPUs

NVIDIA hat zwei Firmware-Probleme bei B200-GPUs festgestellt, die von A4-Instanzen verwendet werden. Diese Probleme können zu Unterbrechungen der Arbeitslast führen, z. B. dazu, dass der Befehl nvidia-smi nicht reagiert. Wenn Sie Arbeitslastunterbrechungen auf A4-VMs feststellen, prüfen Sie, ob eine der folgenden Bedingungen zutrifft:

Wenn eine dieser Bedingungen zutrifft, müssen Sie die GPUs zurücksetzen, die an Ihre A4-VMs angehängt sind. Um zukünftige Unterbrechungen Ihrer Arbeitslast aufgrund von Firmwareproblemen zu vermeiden, empfehlen wir, Ihre GPUs mindestens alle 60 Tage zurückzusetzen. Weitere Informationen finden Sie unter GPUs zurücksetzen.

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

Bei C4-Maschinentypinstanzen, 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 für einzelne Mandanten auf 20 beschränkt.

Die serielle Konsole ist für C4- und C4D-Bare-Metal-Instanzen schreibgeschützt.

Für C4- oder C4D-Bare-Metal-Instanzen 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.

Beim Abbrechen von Jobs auf HPC-Clustern mit 32 Knoten oder mehr wird das Zeitlimit überschritten

Bei großen Jobs in Clustern mit 32 Knoten oder mehr kann die Zeit, die zum Abbrechen eines Jobs benötigt wird, den Standardwert UnkillableStepTimeout von 300 Sekunden überschreiten. Wenn dieser Wert überschritten wird, können die betroffenen Knoten für zukünftige Jobs nicht mehr verwendet werden.

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 noch einmal bereit:

    gcluster deploy -w --force BLUEPRINT_NAME.yaml

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

    1. Stellen Sie über 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 Haupt-Controller-Knotens finden Sie in der Google Cloud Console auf der Seite VM-Instanzen.

    2. Erstellen Sie eine Sicherung 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

Mit dem folgenden Befehl können Sie prüfen, ob die Einstellung geändert wurde:

   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 Laufwerk für die asynchrone Replikation zu ändern, zeigt die gcloud CLI eine Fehlermeldung an, auch wenn die Aktualisierung erfolgreich war.

Wenn Sie prüfen möchten, ob eine Aktualisierung erfolgreich war, rufen Sie die Laufwerkattribute über die gcloud CLI oder die Google Cloud Console auf, 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

Wenn nach einem Hostfehler eine Compute-Instanz auf einen neuen Host verschoben wird, werden beim Abfragen des Metadatenservers möglicherweise die physicalHost-Metadaten des vorherigen Hosts der Instanz angezeigt.

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 Laufwerksnamen führen

In einer MIG können Laufwerksnamenskonflikte auftreten, wenn in der Instanzvorlage Laufwerke angegeben sind, die beim Erstellen der Compute-Instanz 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 der resultierende Name beim Generieren von Laufwerksnamen das Limit für Ressourcennamen von 63 Zeichen überschreitet, kürzt Compute Engine die überzähligen Zeichen am Ende des Instanznamens. Diese Kürzung kann dazu führen, dass für Instanzen mit ähnlichen Namensmustern identische Laufwerksnamen erstellt werden. In diesem Fall versucht die neue Instanz, das vorhandene Laufwerk 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 Modus für mehrere Autoren befindet, wird es von der neuen Instanz angehängt, was zu einer Datenbeschädigung führen kann.

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

Das Erstellen von Reservierungen oder vorausschauenden 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 Anfrage für eine vorausschauende Reservierung zur Überprüfung zu erstellen und einzureichen, treten Probleme auf. Insbesondere kann Folgendes passieren:

  • Das Erstellen der Reservierung kann fehlschlagen. Wenn der Vorgang erfolgreich ist, gilt eine der folgenden Bedingungen:

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

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

  • Die vorausschauende Reservierungsanfrage wurde erstellt. Wenn Sie sie jedoch zur Überprüfung einreichen, wird Ihre Anfrage von Google Cloud abgelehnt.

Sie können die Instanzvorlage, die zum Erstellen einer Reservierung oder einer vorausschauenden Reservierungsanfrage verwendet wird, nicht ersetzen und die Instanzattribute der Vorlage nicht überschreiben. Wenn Sie Ressourcen für A2-, C3- oder G2-Maschinentypen reservieren möchten, gehen Sie stattdessen so vor:

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 zwei lokale SSD-Laufwerke vorhanden sein. Wenn Sie den Maschinentyp c3d-standard-8-lssd verwenden, ist nur ein Laufwerk erforderlich. Wenn die Anzahl der Laufwerke nicht übereinstimmt, wird von der Compute Engine-Steuerungsebene ein Fehler bei der lokalen SSD-Fehlkonfiguration angezeigt. Unter Maschinentypen, die automatisch lokale SSD-Laufwerke anhängen finden Sie Informationen zur Auswahl der richtigen Anzahl lokaler SSD-Laufwerke basierend auf dem lssd-Maschinentyp.

Wenn Sie mit der Google Kubernetes Engine- Google Cloud Console einen Cluster oder Knotenpool erstellen, schlägt entweder die Knotenerstellung fehl oder lokale SSD-Laufwerke 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. Verwenden Sie mehrere TCP-Flüsse, um höhere Raten zu erreichen.

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 Google Cloud Console 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 der Aktualisierung von Compute-Instanzen, die mit dem Befehl gcloud compute instances update oder der API-Methode instances.update initiiert wurden, kann Compute Engine den Namen der Laufwerke Ihrer Compute-Instanz vorübergehend ändern, indem eines der folgenden Suffixe an den ursprünglichen Namen angehängt wird:

  • -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 sind, kann es Stunden dauern, bis sie beendet und neu gestartet werden.

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

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

Fehler beim Erstellen und Leistungseinbußen bei der Verwendung von dynamischen NICs mit GPU-Instanzen

Dynamische NICs werden für die Verwendung mit GPU-Instanzen nicht 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 ist erfolgreich, aber die Leistung der Instanz ist beeinträchtigt, z. B. durch eine deutlich geringere Netzwerkbandbreite.

Diese Probleme treten auf, weil die dynamische NIC-Konfiguration zu Fehlern führt, wenn die Compute Engine versucht, die vNICs 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.

Das manuelle Starten der Hostwartung funktioniert bei X4-Instanzen nicht

Für X4-Instanzen funktioniert das unter Hostwartungsereignis manuell starten beschriebene Verfahren nicht.

Problemumgehung

  1. Beenden Sie die X4-Instanz.
  2. Nachdem sich der Instanzstatus in TERMINATED geändert hat, starten Sie die X4-Instanz.

Informationen zum Beenden oder Neustarten einer X4-Instanz finden Sie unter Compute Engine-Instanz beenden oder neu starten.

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.

Das Simulieren der Hostwartung funktioniert nicht für C4-Bare-Metal-Instanzen.

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

Problemumgehung

Verwenden Sie 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 die C4-Instanz beim Erstellen der VM auf Terminate, anstatt die Live-Migration während Hostwartungsereignissen zu verwenden.

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

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

Leistung geringer als erwartet mit Z3-Bare-Metal-Instanzen auf 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 die Page Pool-Funktion.

Problemumgehung

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

Probleme im Zusammenhang mit der Verwendung von Dynamic Network Interfaces

In diesem Abschnitt werden bekannte Probleme im Zusammenhang mit der Verwendung mehrerer Netzwerkschnittstellen und Dynamic Network Interfaces 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 hinzu, jedoch nicht für dynamische NICs:

  • 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 IP-Adresse der zugehörigen Weiterleitungsregel.
  • Wenn Sie einem Passthrough-Network-Load-Balancer ein Backend hinzufügen, erstellt der Gast-Agent eine lokale Route für die IP-Adresse der zugehörigen Weiterleitungsregel.

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

So fügen Sie die IP-Adressen manuell hinzu, um dieses Problem zu beheben:

  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 darauf, dass in /etc/default/instance_configs.cfg die Einstellung ip_aliases auf true festgelegt ist.

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

      systemctl restart google-guest-agent

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

    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 von dynamischen NICs in den 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 von 20250901.00 bis 20251120.01 ausgeführt wird, können die folgenden Probleme auftreten:

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

    Wenn Sie Befehle im Gastbetriebssystem ausführen, die auf dynamische NICs verweisen, erhalten Sie möglicherweise eine Fehlermeldung, die 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, Plug-in-basierte Architektur migriert, um die Modularität zu verbessern. Die neue Architektur unterstützte anfangs nicht die automatische Installation und Verwaltung von dynamischen NICs.

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 aktuelle Version finden Sie unter Gastumgebung aktualisieren.
  2. Informationen zum Prüfen 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 mit den Gast-Agent-Versionen 20250901.00 bis 20251120.01 vorübergehend umgehen. Folgen Sie dazu der Anleitung unter Abwärtskompatibilität, um zur vorherigen Gast-Agent-Architektur zurückzukehren.

Die Paketerfassung kann dazu führen, dass Pakete aufgrund fehlender VLAN-Tags in den Ethernet-Headern verworfen werden.

Die Paketerfassung bei Verwendung einer dynamischen NIC kann zu Paketverlusten führen. Verworfene Pakete können auftreten, wenn die Pipeline vorzeitig beendet wird. Das Problem betrifft sowohl sitzungsbasierte als auch nicht sitzungsbasierte Modi.

Ursache

Verworfene Pakete treten während der Paketerfassung auf, wenn die Pipeline vorzeitig beendet wird (Abfangen von eingehendem Traffic und erneutes Einfügen von ausgehendem Traffic). Durch die vorzeitige Beendigung fehlt die VLAN-ID im Ethernet-Header des eingehenden Pakets. Da das ausgehende Paket vom geänderten eingehenden Paket abgeleitet wird, fehlt auch im ausgehenden 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 der Paketerfassung basieren, z. B. Firewall-Endpunkte.

Dynamische NIC-Vorgänge schlagen fehl, wenn sich eine Compute-Instanz in mehreren Instanzgruppen befindet

Wenn Sie eine dynamische NIC hinzufügen oder löschen und der Vorgang im Status RUNNING bei 0 % Fortschritt hängen bleibt und schließlich mit einem INTERNAL_ERROR fehlschlägt, kann dies daran liegen, dass sich die Compute-Instanz in mehreren Instanzgruppen (verwaltet oder nicht verwaltet) befindet.

Damit der Vorgang abgeschlossen werden kann, entfernen Sie die Instanz aus allen Instanzgruppen bis auf eine. Sie können eine Instanz aus einer verwalteten Instanzgruppe entfernen oder eine Instanz aus einer nicht verwalteten Instanzgruppe entfernen.

Bekannte Probleme bei Linux-Compute-Instanzen

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

Fehler beim Paketupgrade 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 ähnlicher Fehler wie dieser 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

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

Lösung

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

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 Upgradeproblem tritt daher bei diesen oder späteren Builds nicht auf.

OS Login wird unter 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 Startskripts

Wenn Ihre Compute-Instanz die Gast-Agent-Version 20251115.00 verwendet, schlägt das Abrufen eines Startskripts mit dem Metadatenschlüssel startup-script-url fehl, wenn die URL das Format https://storage.googleapis.com/ verwendet, das auf der Seite Startskripts 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-Speicher-URI: gs://BUCKET/FILE

VM-Instanzen, die Debian 11-Images vor Version v20250728 verwenden, können apt update nicht ausführen

Am 22. Juli 2025 hat die Debian-Community Debian 11 (Bullseye)-Backports aus dem Haupt-Debian-Upstream entfernt. Dieses Update führt dazu, dass sudo apt update mit dem folgenden 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 Image-Version 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

Die Installation des ubuntu-desktop-Pakets unterbricht die Netzwerkverbindung, 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 ruft 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 unter /usr/lib/netplan/00-network-manager-all.yaml eingefügt, die Folgendes enthält:

network:
  version: 2
  renderer: NetworkManager

Diese Konfiguration steht im Konflikt mit unserer networkd-basierten frühen Bereitstellung 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 Linux-Dateisystempartition der nicht zugänglichen Compute-Instanz bereitgestellt haben, führen Sie den folgenden Befehl aus. Ersetzen Sie dabei /rescue durch Ihren Bereitstellungspunkt:

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

  3. Fahren Sie mit dem Neustart der nicht zugänglichen Compute-Instanz fort.

Compute-Instanzen, die die Ubuntu-Betriebssystemversion v20250530 verwenden, zeigen einen falschen FQDN an

In den folgenden Fällen wird möglicherweise ein falscher voll qualifizierter Domainname (FQDN) mit dem Suffix .local angezeigt:

  • Aktualisieren Sie das Paket google-compute-engine auf die Version 20250328.00.
  • Starten Sie Compute-Instanzen aus 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, wird möglicherweise ein FQDN wie der folgende angezeigt:

   [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 fügt die guest-config-Paketversion 20250328.00 dem Suchpfad local hinzu, da eine neue Konfigurationsdatei eingeführt wurde: 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

Wenn dieser local-Eintrag im Suchpfad in der Datei /etc/resolv.conf vorhanden ist, wird dem Hostnamen ein .local-Element angehängt, wenn ein FQDN angefordert wird.

In der Version 20250501 von guest-configs ist das Problem bereits behoben, aber Canonical hat die Korrektur noch nicht in seine Images integriert.

Problemumgehung

  1. Ändern Sie die Konfigurationsdatei für die Netzwerknamensauflösung /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 systemd-resolved-Dienst 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

Fehlendes mkfs.ext4 auf openSUSE-Images

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

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 gestartet werden

Nachdem Sie den Maschinentyp für eine Compute-Instanz mit SUSE Enterprise Linux geändert haben, kann es sein, dass die Instanz nicht gestartet wird und der folgende Fehler in der seriellen Konsole angezeigt wird:

            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 filesystem), das verschiedene Instanztypen unterstützt. Dazu werden bei der ersten Image-Erstellung die --no-hostonly --no-hostonly-cmdline -o multipath-Flags verwendet. Wenn jedoch ein neuer Kernel installiert oder die initramfs neu generiert wird, was bei Systemupdates der Fall ist, werden diese Flags standardmäßig weggelassen. Dies führt zu einem kleineren initramfs, das speziell auf die Hardware des aktuellen Systems zugeschnitten ist. Treiber, die für andere Instanztypen erforderlich sind, werden möglicherweise ausgeschlossen.

C3-Instanzen verwenden beispielsweise NVMe-Laufwerke, für die bestimmte Module in der 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 Wiederherstellung. 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 mit SUSE 12-Images

Z3-Compute-Instanzen, die SUSE Linux Enterprise Server (SLES) 12-Images verwenden, haben eine deutlich geringere Leistung als erwartet für IOPS auf lokalen SSD-Laufwerken.

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 Netzwerkkarten (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 vorhersagbarer Netzwerkschnittstellennamen nicht unterstützt, wenn mindestens eine NIC nicht die VirtIO-Schnittstelle verwendet.

Lösung

Die Netzwerkverbindung kann wiederhergestellt werden, indem die Compute-Instanz beendet und gestartet wird, 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
Auflö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 Treiber vioscsi, der für SCSI-Laufwerke verwendet wird, legt das Flag removable fest, sodass die Laufwerke als Wechseldatenträger behandelt werden. Dies führt zu unerwarteten Zugriffsbeschränkungen in Windows auf Laufwerke, die Gruppenrichtlinienobjekten (GPOs) unterliegen, die auf Wechselmedien abzielen.

Gast-Agent kann unter Windows Server 2012 R2 und früheren Versionen nicht gestartet werden

Nach dem Aktualisieren der Gast-Agent-Pakete auf Instanzen, auf denen ältere Windows-Betriebssysteme ausgeführt werden (z. B. Windows Server 2012 R2, Windows Server 2012 oder Windows Server 2008 R2). Wenn Sie die Binärdatei manuell ausführen, erhalten Sie eine Fehlermeldung, dass die Binärdatei nicht erkannt wird.

Upstream Go (Golang) unterstützt Windows Server 2012 R2 und frühere Versionen ab Go 1.21 nicht mehr. Gast-Agent-Releases, die mit Go 1.21 oder höher erstellt wurden, können auf diesen Betriebssystemen nicht ausgeführt werden.

Problemumgehung

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

  • Betriebssystem aktualisieren: Aktualisieren Sie Ihre VM-Instanz auf eine unterstützte Version, z. B. Windows Server 2016 oder höher. Weitere Informationen finden Sie unter Ende des Supports für Windows.

  • Zurücksetzen auf eine frühere Gast-Agent-Version: Wenn Sie weiterhin Windows Server 2012 R2 oder früher ausführen müssen, installieren Sie kompatible Gast-Agent-Pakete von einer anderen laufenden Compute-Instanz oder einem Snapshot neu:

    1. Prüfen Sie auf der funktionierenden Compute-Instanz die Version der Pakete google-compute-engine-windows und google-compute-engine-metadata-scripts.
    2. Rufen Sie das Cache-Verzeichnis Googet auf und kopieren Sie die C:\ProgramData\Googet\cache\` and copy the.goo-Dateien für die oben genannten Pakete auf die fehlerhafte VM.
    3. Installieren Sie auf der fehlerhaften VM die kopierten Pakete nacheinander mit googet install -reinstall PACKAGE_NAME.goo.

  • Wenn Sie verhindern möchten, dass der Gast-Agent auf eine inkompatible Version aktualisiert wird, deaktivieren Sie die automatische Aktualisierung für den Gast-Agent.

Gast-Agent kann nicht gestartet werden

Der Windows-Gast-Agent in der Version 20251011.00 kann unter bestimmten Lastbedingungen nicht gestartet werden.

Ursache In der Windows-Gast-Agent-Paketerstellung für Version 20251011.00 wird der Startmodus des Windows-Gast-Agents im Windows-Dienstmanager 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 der 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 können bei Windows-Instanzen mit nicht englischen Sprachnamen fehlschlagen

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

Windows Server 2016 wird auf C3D-Maschinentypen mit 180 oder mehr vCPUs nicht gestartet.

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

  • 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 nicht fortgesetzt werden, wenn sie gesperrt sind. Bis dieses Problem behoben ist, wird die Funktion zum Sperren und Fortsetzen für Windows Server 2025, Windows 11 24h2 und Windows 11 25h2 nicht unterstützt.

Fehler beim Messen der NTP-Zeitabweichung 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 der NTP-Abweichung mit dem folgenden Befehl Fehler erzeugt:

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 Bootlaufwerk nach dem Aktualisieren einer Compute-Instanz von Generation 1 oder 2 auf eine Instanz der Generation 3 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 Maschinenreihe (Generation 1 oder 2), die eine SCSI-Laufwerksschnittstelle verwendet, in eine neuere Maschinenreihe (Generation 3 oder höher) ändern möchten, die eine NVMe-Laufwerksschnittstelle verwendet, führen Sie ein Sysprep für den Windows-PnP-Treiber aus, bevor Sie die Compute-Instanz herunterfahren. Dieses Sysprep bereitet nur Gerätetreiber vor und prüft, ob beim nächsten Start alle Laufwerksschnittstellentypen für das Bootlaufwerk gescannt werden.

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

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

So ändern Sie die Maschinenreihe einer Compute-Instanz:

  1. Beenden Sie die Compute-Instanz.
  2. Bearbeiten Sie die Compute-Instanz, um den neuen Maschinentyp zu verwenden.
  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 Migrationsanforderungen, um sicherzustellen, dass Sie sie erfüllen. Versuchen Sie es dann noch einmal.

Begrenzte Anzahl von Laufwerken, die für Maschinenserien mit NVMe-Laufwerken angehängt werden können

Compute-Instanzen, die die NVMe-Laufwerksschnittstelle und ein Microsoft Windows-Betriebssystem-Image verwenden, haben für bestimmte Maschinenreihen ein Limit von 16 Laufwerken für den Laufwerksanhang. Dieses Limit gilt für die Maschinenserien N4, C3, C3D und M3.

Maschinenserien wie C4, C4D, N4D und M4 unterstützen mehr als 16 Laufwerke, wenn Sie einen kompatiblen NVMe-Treiber wie den Microsoft StorNVMe-Treiber verwenden.

Dieses Limit gilt nicht für lokalen SSD-Speicher. Um Fehler zu vermeiden, konsolidieren Sie Ihren Persistent Disk- und Hyperdisk-Speicher auf maximal 16 Laufwerke pro Compute-Instanz für betroffene Maschinenreihen.

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 vom 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 Maschinenreihe der dritten Generation oder höher ändern oder bevor Sie einen Snapshot eines Bootlaufwerks erstellen, mit dem neue Compute-Instanzen erstellt werden, die eine Maschinenreihe 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 verbessert.

Geringere Leistung für 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 über alle Hyperdisk Extreme-Volumes erreichen, die an die Instanz angehängt sind.

Lösung

Wenn Sie mit N2-Instanzen, auf denen Windows ausgeführt wird, 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

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, können bei Verwendung von Google Virtual NIC (gVNIC) einen schlechten Netzwerkdurchsatz verursachen.

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 sowie C4D- und C3D-Maschinentypen mit mehr als 180 vCPUs unterstützen die Betriebssystem-Images von Windows Server 2012 und 2016 nicht. 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 nichtflüchtigen Speichers 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 zum Anhängen und Ändern der Größe von Laufwerken.

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 dem Windows-Betriebssystem ausgeführt werden, und Sie ein Hyperdisk- oder Persistent Disk-Volume ändern, müssen Sie die Compute-Instanz neu starten, damit die Änderungen am Laufwerk erkannt werden.