Bekannte Probleme

Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von Compute Engine 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.

Sie können die Google Cloud Console nicht verwenden, um Spot-VMs für A4 und A3 Ultra zu erstellen.

Sie können keine Spot-VM erstellen, die die A4- oder A3-Ultra-Maschinenserie verwendet, wenn Sie die Google Cloud Console verwenden. Wenn Sie auf der Seite Instanz erstellen in der Ansicht Maschinenkonfiguration einen GPU-Typ für diese Maschinenreihen auswählen, wird in der Ansicht Erweitert die Meldung Eine Reservierung ist erforderlich angezeigt. Sie können dann in der Liste VM-Bereitstellungsmodell nicht die Option Spot auswählen.

Um das Problem zu umgehen, verwenden Sie die gcloud CLI oder REST, um Spot-VMs für A4 und A3 Ultra zu erstellen. Alternativ können Sie die Google Cloud -Konsole verwenden, um A4- und A3-Ultra-VMs zu erstellen, die das reservierungsgebundene Bereitstellungsmodell verwenden.

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

Wenn Sie den Befehl gcloud compute disks update verwenden, um die IOPS und den Durchsatz auf einer primären Festplatte für die asynchrone Replikation zu ändern, wird in der Google Cloud CLI eine Fehlermeldung angezeigt, auch wenn die Aktualisierung erfolgreich war.

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

Der Metadatenserver zeigt möglicherweise alte physicalHost-VM-Metadaten an.

Nach einem Hostfehler, durch den eine Instanz auf einen neuen Host verschoben wird, kann es beim Abfragen des Metadatenservers passieren, dass 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 der VM Laufwerke erstellt werden sollen, und der Wert baseInstanceName 54 Zeichen überschreitet. 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. Durch diese Kürzung können identische Laufwerksnamen für Instanzen mit ähnlichen Benennungsmustern entstehen. In diesem Fall wird versucht, das vorhandene Laufwerk an die neue Instanz anzuhängen. Wenn das Laufwerk bereits an eine andere 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 an die neue Instanz angehängt, was möglicherweise zu Datenbeschädigung führt.

Um Konflikte bei Festplattennamen zu vermeiden, sollte der Wert baseInstanceName eine maximale Länge von 54 Zeichen haben.

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 Anfrage für eine vorausschauende Reservierung zu erstellen und zur Überprüfung einzureichen, treten Probleme auf. Zum Beispiel:

  • 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 genutzt, wenn Sie VMs mit übereinstimmenden Attributen erstellen.

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

  • Das Erstellen der zukünftigen Reservierungsanfrage ist erfolgreich. Wenn Sie den Antrag jedoch zur Überprüfung einreichen, lehnt Google Cloud Ihren Antrag ab.

Sie können die Instanzvorlage, die zum Erstellen einer Reservierung oder zukünftigen Reservierungsanfrage verwendet wird, nicht ersetzen oder die VM-Attribute der Vorlage überschreiben. Wenn Sie Ressourcen für A2-, C3- oder G2-Maschinentypen reservieren möchten, haben Sie folgende Möglichkeiten:

Einschränkungen bei Verwendung von c3-standard-*-lssd- und c3d-standard-*-lssd-Maschinentypen mit Google Kubernetes Engine

Wenn Sie die Google Kubernetes Engine API verwenden, muss der Knotenpool mit angehängten lokalen SSD-Laufwerken die gleiche Anzahl an SSDs wie der ausgewählte C3-Maschinentyp haben. Wenn Sie beispielsweise eine VM mit dem c3-standard-8-lssd erstellen möchten, müssen Sie zwei SSD-Laufwerke verwenden, während für c3d-standard-8-lssd nur ein SSD-Laufwerk erforderlich ist. Wenn die Anzahl der Laufwerke nicht übereinstimmt, wird ein Fehler bei der lokalen SSD-Fehlkonfiguration von der Compute Engine-Steuerungsebene angezeigt. Im Dokument Maschinenfamilie für allgemeine Zwecke finden Sie Informationen zum Auswählen der richtigen Anzahl lokaler SSD-Laufwerke basierend auf dem C3- oder C3D-lssd-Maschinentyp.

Wenn Sie mit der Google Kubernetes Engine- Google Cloud Console einen Cluster oder Knotenpool mit c3-standard-*-lssd- und c3d-standard-*-lssd-VMs erstellen, schlägt die Erstellung des Knotens fehl oder es werden lokale SSDs nicht als sitzungsspezifischer Speicher erkannt.

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

Bei C3D-VMs 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 erzielen, verwenden Sie mehrere TCP-Flows.

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

Wenn die CPU Ihrer VM einen Thread pro Kern verwendet, skaliert der Cloud Monitoring-Messwert zur Beobachtbarkeit von CPU-Auslastung in ComputeEngine > VM-Instanzen > Sichtbarkeit nur auf 50 %. Zwei Threads pro Kern sind für alle Maschinentypen mit Ausnahme von Tau T2D die Standardeinstellung. Weitere Informationen finden Sie unter Anzahl der Threads pro Kern festlegen.

Wenn Sie die CPU-Auslastung Ihrer VM 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 VM-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 VM-Instanz-Updates, die mit dem Befehl gcloud compute instances update oder der API-Methode instances.update initiiert wird, kann Compute Engine den Namen der Laufwerke Ihrer VM 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 Bare-Metal-Instanzen

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.

Probleme bei der Verwendung von Dynamic Network Interfaces

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

Paketverlust bei benutzerdefinierten MTU-Größen

Bei einer Dynamic NIC mit einer übergeordneten vNIC kann es bei benutzerdefinierten MTU-Größen zu Paketverlusten kommen.

Problemumgehung

Verwenden Sie eine der folgenden MTU-Größen, um Paketverluste zu vermeiden:

  • 1.460 Byte (der Standardwert für VPC-Netzwerke)
  • 1.500 Byte (Standard-Ethernet)
  • 8.896 Byte (der höchstmögliche Wert)

Firewall-Interaktionen bei der Wiederverwendung einer VLAN-ID mit dynamischen NICs

Wenn Sie auf einer Instanz eine VLAN-ID für eine neue dynamische NIC wiederverwenden, hat das Auswirkungen auf die Firewall-Verbindungsüberwachung. Wenn Sie eine dynamische NIC löschen und eine Ersatz-NIC mit derselben VLAN-ID erstellen, werden die Einträge in der Firewall-Verbindungsverfolgungstabelle nicht automatisch gelöscht. Das folgende Beispiel zeigt die relevanten Sicherheitsaspekte:

  1. Eine Compute-Instanz hat eine dynamische Beispiel-NIC mit der VLAN-ID 4, die mit einem Subnetz im VPC-Netzwerk network-1 verbunden ist.
  2. Die Instanz sendet Pakete an die Ziel-IP-Adresse und den Zielport 192.0.2.7:443. Die entsprechenden Firewallregeln für ausgehenden Traffic lassen die ausgehende Verbindung zu.
  3. Da Cloud NGFW-Regeln zustandsbehaftet sind, wird durch die zugelassene ausgehende Verbindung ein Eintrag in der Firewall-Verbindungs-Tracking-Tabelle erstellt, der eingehende Pakete von der Quell-IP-Adresse und dem Quellport 192.0.2.7:443 zulässt.
  4. Sie löschen die Beispiel-Dynamic NIC und erstellen eine Ersatz-Dynamic NIC. Die Ersatz-Dynamic NIC verwendet ebenfalls die VLAN-ID 4, stellt aber eine Verbindung zu einem Subnetz in einem anderen VPC-Netzwerk, network-2, her.
  5. Alle nicht abgelaufenen Einträge in der Firewall-Verbindungstracking-Tabelle, die für die ursprüngliche dynamische NIC galten, gelten auch für die Ersatz-NIC. Das bedeutet, dass eine Ressource im network-2-VPC-Netzwerk Pakete senden kann, deren Quellen mit 192.0.2.7:443 übereinstimmen, und die Compute-Instanz sie akzeptiert, ohne dass Firewallregeln für eingehenden Traffic ausgewertet werden müssen.

Weitere Informationen zur Verbindungsüberwachung und zu Firewallregeln finden Sie in der Dokumentation zur Cloud Firewall der nächsten Generation unter Spezifikationen.

Lösung

Wenn Sie pro Instanz eine dynamische NIC erstellen müssen, die dieselbe VLAN-ID wie eine dynamische NIC verwendet, die aus der Instanz entfernt wurde:

  • Warten Sie mindestens 10 Minuten zwischen dem Löschen der ursprünglichen dynamischen NIC und dem Erstellen der Ersatz-NIC.
  • Beenden Sie die Instanz, löschen Sie die ursprüngliche dynamische NIC und erstellen Sie die Ersatz-NIC. Starten Sie dann die Instanz.

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 ausgehende Paket vom geänderten eingehenden Paket abgeleitet wird, fehlt dem ausgehenden Paket auch die VLAN-ID. Dies führt zu einer falschen Auswahl des Endpunktindex und zu Paketverlusten.

Problemumgehung

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

Bekannte Probleme bei Linux-VM-Instanzen

Dies sind die bekannten Probleme bei Linux-VMs.

Bei Ubuntu-VMs, die die Betriebssystem-Image-Version v20250530 verwenden, wird ein falscher FQDN angezeigt

Möglicherweise wird ein falscher vollqualifizierter 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 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 mit der guest-config-Paketversion 20250328.00 der Pfad local zum Suchpfad hinzugefügt. Das liegt an der Einführung einer neuen Konfigurationsdatei: 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.

Hinweis: In Version 20250501 von guest-configs wurde das Problem bereits behoben. 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

SUSE Enterprise-VM kann nach dem Ändern von Instanztypen nicht gestartet werden

Nachdem Sie den Instanztyp einer SUSE Linux Enterprise-VM geändert haben, kann es vorkommen, dass sie nicht mehr gestartet wird. In der seriellen Konsole wird dann wiederholt 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 filesystem), 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 das initramfs neu generiert wird, was bei Systemupdates geschieht, werden diese Flags standardmäßig ausgelassen. Dadurch wird ein kleineres initramfs erstellt, 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, auf eine 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 Rettungs-VM. Verwenden Sie den Befehl chroot, um auf das Bootlaufwerk der betroffenen VM 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

Z3-VMs mit SLES-Images (SUSE Linux Enterprise Server) 12 haben eine deutlich geringere als erwartete Leistung für IOPS auf lokalen SSD-Festplatten.

Ursache

Dies ist ein Problem im SLES 12-Code.

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-VMs verlieren nach dem Neustart den Netzwerkzugriff

Wenn Ihre CentOS- oder RHEL 7-VMs 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 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 VM 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 VM neu.

Das folgende Problem wurde am 13. Januar 2025 behoben.

Öffentliche Google Cloud SUSE-Images enthalten nicht die erforderliche udev-Konfiguration zum Erstellen von Symlinks für lokale C3- und C3D-SSD-Geräte.

Lösung

Informationen zum Hinzufügen von udev-Regeln für SUSE- und benutzerdefinierte Images finden Sie unter Symlinks nicht in C3 und C3D mit lokaler SSD erstellt.

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 VM 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 für Windows-VM-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 VMs 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-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.

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

Windows Server 2025 und Windows 11 24H2 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 und Windows 11 24H2 nicht unterstützt.

Fehler beim Messen der NTP-Zeitabdrift mit w32tm auf Windows-VMs

Bei Windows-VMs in Compute Engine, auf denen VirtIO-NICs ausgeführt werden, 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-VMs mit VirtIO-NICs. Bei VMs, die gVNIC 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 VM von Gen 1 oder 2 auf eine VM der 3. Generation oder höher

Windows Server bindet das Bootlaufwerk beim ersten Start an den ursprünglichen Laufwerksschnittstellentyp. Wenn Sie eine vorhandene VM von einer älteren Maschinenserie, die eine SCSI-Festplattenschnittstelle verwendet, in eine neuere Maschinenserie ändern möchten, die eine NVMe-Festplattenschnittstelle verwendet, führen Sie vor dem Herunterfahren der VM einen Windows-PnP-Treibersysprep durch. Bei diesem Sysprep werden nur Gerätetreiber vorbereitet und es wird überprüft, ob beim nächsten Start alle Festplattenschnittstellentypen nach dem Startlaufwerk durchsucht werden.

So aktualisieren Sie die Maschinenserie einer VM:

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

PS C:\> start rundll32.exe sppnp.dll,Sysprep_Generalize_Pnp -wait
  1. Halten Sie die VM an.
  2. Ändern Sie die VM in den neuen VM-Maschinentyp.
  3. Starten Sie die VM.

Wenn die neue VM nicht richtig startet, ändern Sie die VM wieder in den ursprünglichen Maschinentyp, damit sie wieder funktioniert. Er sollte erfolgreich starten. Prüfen Sie die Anforderungen für die Migration. Wiederholen Sie dann die Anleitung.

Eingeschränkte Bandbreite mit gVNIC auf Windows-VMs

Der in den von Compute Engine angebotenen Windows-Images enthaltene gVNIC-Treiber kann eine Netzwerkbandbreite von bis zu 50 Gbit/s auf Windows-Instanzen erreichen, sowohl für die Standardnetzwerkleistung als auch für die Tier_1-Netzwerkleistung pro VM. Eine aktualisierte Version des gVNIC-Treibers kann eine Line-Rate-Leistung (bis zu 200 Gbit/s) und Unterstützung für Jumbo-Frames bieten.

Der aktualisierte Treiber ist nur für Maschinenserien der dritten Generation und höher (mit Ausnahme von N4) verfügbar. Weitere Informationen finden Sie unter gVNIC-Version unter Windows aktualisieren.

Begrenzte Anzahl von Laufwerken für neuere VM-Maschinenreihen

Für VMs, die unter Microsoft Windows mit der NVMe-Laufwerkschnittstelle ausgeführt werden (einschließlich T2A, aller VMs der dritten Generation und neuerer VMs), gilt ein Limit von 16 Laufwerken. Um Fehler zu vermeiden, sollten Sie Ihren Persistent Disk- und Hyperdisk-Speicher auf maximal 16 Laufwerke pro VM konsolidieren. Lokaler SSD-Speicher ist von diesem Problem ausgeschlossen.

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

Wenn Sie NVMe auf einer VM verwenden möchten, die Microsoft Windows verwendet, und die VM 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 VM aktualisieren, bevor Sie den Maschinentyp in eine Maschinenserie der dritten Generation ändern oder bevor Sie einen Snapshot eines Bootlaufwerks erstellen, mit dem neue VMs erstellt werden, die eine Maschinenserie der dritten Generation 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 unter Microsoft Windows mit C3- und C3D-VMs

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

Die Leistung wird derzeit verbessert.

Schlechter Netzwerkdurchsatz bei Verwendung von gVNIC

Windows Server 2022- und Windows 11-VMs, die das goVGet-Paket der goVGet-Version 1.0.0@44 oder eine frühere Version 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 VM 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 C4D- und C3D-vCPU-Maschinentypen unterstützen keine Windows-Betriebssystem-Images

C4D- und C3D-Maschinentypen mit mehr als 180 vCPUs unterstützen die Betriebssystem-Images von Windows Server 2012 und 2016 nicht. Größere 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-VMs, 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-VMs, die mit mehr als 255 vCPUs und Windows 2025 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-VMs

Das Hinzufügen oder Ändern der Größe einer Hyperdisk oder eines nichtflüchtigen Speichers für eine laufende M3-, C3-, C3D- oder C4D-VM funktioniert bei bestimmten Windows-Gästen derzeit nicht wie erwartet. Windows Server 2012 R2 und Windows Server 2016 und die entsprechenden Nicht-Server-Windows-Varianten reagieren nicht ordnungsgemäß auf die Befehle „Laufwerk anhängen” und „Laufwerkgröße anpassen”.

Wenn Sie beispielsweise ein Laufwerk von einer ausgeführten M3-VM entfernen, wird die Festplatte von einer Windows Server-Instanz getrennt, ohne dass das Windows-Betriebssystem erkennt, dass das Laufwerk verworfen ist. Nachfolgende Schreibvorgänge auf dem Laufwerk geben einen allgemeinen Fehler zurück.

Lösung

Sie müssen die unter Windows ausgeführte M3-, C3-, C3D- oder C4D-VM neu starten, nachdem Sie eine Hyperdisk oder einen nichtflüchtigen Speicher geändert haben, damit die Änderungen am Laufwerk von diesen Gästen erkannt werden.