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 Bekannte Probleme mit Confidential VMs.

Preisschätzung beim Erstellen von Z3-VMs nicht verfügbar

Während der Vorschau für Z3 ist in der Google Cloud Console keine Preisschätzung verfügbar. Informationen zu den Preisen für eine Z3-VM finden Sie unter Google Cloud SKUs.

Allgemeine Probleme

Die folgenden Probleme enthalten Anleitungen zur Fehlerbehebung oder allgemeine Informationen.

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 um eine zukünftige Reservierungsanfrage zur Prüfung zu erstellen und einzureichen, treten Probleme auf. Zum Beispiel:

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

    • Wenn Sie eine automatisch genutzte Reservierung (Standard) erstellt haben, wird beim Erstellen von VMs mit übereinstimmenden Attributen die Reservierung nicht genutzt.

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

  • Die zukünftige Reservierungsanfrage ist erfolgreich erstellt. Wenn Sie sie jedoch zur Prüfung einreichen, lehnt Google Cloud Ihre Anfrage ab.

Sie können weder die Instanzvorlage verwenden, die zum Erstellen einer Reservierung oder für eine zukünftige Reservierungsanfrage verwendet wird, noch die VM-Attribute der Vorlage überschreiben. Wenn Sie Ressourcen für die Maschinentypen A2, C3 oder G2 reservieren möchten, führen Sie einen der folgenden Schritte aus:

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 Laufwerknummer nicht übereinstimmt, erhalten Sie von der Compute Engine-Steuerungsebene einen Fehler bei der lokalen SSD-Fehlkonfiguration. Im Dokument Maschinenfamilie für allgemeine Zwecke finden Sie die korrekte Anzahl lokaler SSD-Laufwerke anhand des C3- oder C3D-Maschinentyps lssd.

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.

TCP-Durchsatzschwankungen 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. Verwenden Sie mehrere TCP-Abläufe, um höhere Raten zu erreichen.

Verwaltete Instanzgruppe mit T2D-Maschinenserie wird nicht automatisch wie erwartet skaliert

Verwaltete Instanzgruppen (MIGs), die T2D-Maschinen-VMs in Projekten haben, die vor dem 18. Juni 2023 erstellt wurden, erkennen die CPU-Auslastung auf VMs nicht in der MIG korrekt. In solchen Projekten ist das Autoscaling basierend auf der CPU-Auslastung in einer MIG mit T2D-Maschinen-VMs möglicherweise falsch.

Wenn Sie eine Fehlerkorrektur für Ihr Projekt anwenden möchten, wenden Sie sich an Cloud Customer Care.

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 der Google 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:

Das Verkleinern oder Löschen bestimmter Reservierungen verhindert die Nutzung anderer Reservierungen durch VMs

Wenn Sie eine bestimmte Reservierung, die von einer oder mehreren VMs genutzt wurde, verkleinern oder löschen, können die verwaisten VMs keine Reservierungen nutzen.

Weitere Informationen finden Sie unter Reservierungen löschen und Größe von Reservierungen anpassen.

Das Verschieben von VMs oder Laufwerken mithilfe der moveInstance API oder der gcloud CLI führt zu unerwartetem Verhalten

Das Verschieben von VM-Instanzen mit dem Befehl gcloud compute instances move oder der Methode project.moveInstance kann zu Datenverlust, Löschen der VM oder anderen unerwarteten Verhaltensweisen führen.

Beim Verschieben von VMs folgen Sie der Anleitung unter VM-Instanz zwischen Zonen oder Regionen verschieben.

Laufwerke, die an VMs mit n2d-standard-64-Maschinentypen angehängt sind, erreichen nicht konsistent die Leistungsgrenzen

Nichtflüchtige Speicher, die an VMs mit n2d-standard-64-Maschinentypen angehängt sind, erreichen nicht konsistent die maximale Leistungsbegrenzung von 100.000 IOPS. Dies gilt sowohl für Lese- als auch für Schreib-IOPS.

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.

MBR-Images mit C3-VMs mit lokaler SSD verwenden

Eine C3-VM, die mit c3-standard-44-lssd und größeren Maschinentypen erstellt wurde, wird mit MBR-Images nicht erfolgreich gestartet.

Kann nicht unterstützte PD-Standard- und PD-Extrem-Laufwerke an C3- und M3-VMs anhängen

Nichtflüchtige Standardspeicher (pd-standard) sind der Standard-Bootlaufwerktyp bei Verwendung der Google Cloud CLI oder der Compute Engine API. pd-standard-Laufwerke werden jedoch nicht auf C3- und M3-VMs unterstützt. Darüber hinaus unterstützen C3-VMs keine pd-extreme-Laufwerke.

Die folgenden Probleme können bei der Verwendung der Google Cloud CLI oder der Compute Engine API auftreten:

  • pd-standard ist als Standard-Bootlaufwerktyp konfiguriert und das Laufwerk wird erstellt, sofern Sie keinen anderen unterstützten Bootlaufwerktyp angeben, z. B. pd-balanced oder pd-ssd.
  • Vor der allgemeinen Verfügbarkeit (General Availability, GA) von C3 konnten Sie pd-extreme-Laufwerke an C3-VMs und pd-standard-Laufwerke an C3- und M3-VMs anhängen.

Wenn Sie eine C3- oder M3-VM mit einem nicht unterstützten Laufwerkstyp erstellt haben, verschieben Sie Ihre Daten in einen neuen unterstützten Laufwerkstyp. Eine Beschreibung hierzu finden Sie unter Typ des nichtflüchtigen Speichers ändern. Wenn Sie den Laufwerkstyp nicht ändern, funktionieren die VMs weiterhin. Einige Vorgänge wie das Trennen und Wiederanhängen von Laufwerken schlagen jedoch fehl.

Problemumgehung

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

  • Verwenden Sie die Google Cloud Console, um C3- oder M3-VMs zu erstellen und Laufwerke anzuhängen. Die Console erstellt C3- und M3-VMs mit pd-balanced-Bootlaufwerken und lässt das Anhängen von nicht unterstützten Laufwerktypen an VMs nicht zu.
  • Wenn Sie die Google Cloud CLI oder die Compute Engine API verwenden, konfigurieren Sie beim Erstellen einer VM explizit ein Bootlaufwerk vom Typ pd-balanced oder pd-ssd.

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 Linux-VM-Instanzen

Dies sind die bekannten Probleme bei Linux-VMs.

RHEL 7- und CentOS-VMs verlieren nach Neustart den Netzwerkzugriff

Die von Google bereitgestellten CentOS- und Red Hat Enterprise Linux (RHEL) 7-Betriebssystem-Images haben vorhersehbare Netzwerkschnittstellennamen standardmäßig deaktiviert.

Wenn Ihre CentOS- oder RHEL 7-VMs jedoch mehrere Netzwerkschnittstellenkarten (NICs) haben und eine dieser NICs die VirtIO-Schnittstelle nicht verwendet, geht der Netzwerkzugriff beim Neustart möglicherweise verloren. Dies liegt daran, dass RHEL die Deaktivierung vorhersehbarer Netzwerkschnittstellennamen nicht unterstützt, wenn mindestens eine NIC die VirtIO-Schnittstelle nicht verwendet.

Lösung

Die Netzwerkverbindung kann durch Beenden und Starten der VM wiederhergestellt werden, 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.

Ö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

  • Instanzen mit Windows 11, Version 22H2 können nicht gestartet werden. Verwenden Sie Windows 11, Version 21H2, bis das Problem behoben ist.
  • 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.

Fehler beim Messen der NTP-Zeitabweichung 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 das Messen von NTP-Drifts zu Fehlern führt, wenn der folgende Befehl verwendet wird:

w32tm /stripchart /computer:metadata.google.internal

Die Fehler sehen in 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 Programmfehler 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.

Das Verschieben einer Windows-VM auf eine Maschinenserie der dritten Generation führt zu Bootproblemen

Wenn Sie eine Windows-VM in eine Maschinenserie einer dritten Generation verschieben (z. B. C3 oder H3) von einer Maschinenserie der ersten oder zweiten Generation (z. B. N1 oder N2), startet die VM beim Neustart nicht.

So umgehen Sie das Problem:

  1. Prüfen Sie mit dem Befehl gcloud compute disks describe, ob das Bootlaufwerk der VM, die Sie aktualisieren möchten, mit den Maschinentypen der dritten Generation kompatibel ist:

    gcloud compute disks describe DISK_NAME --zone=ZONE

    Ersetzen Sie Folgendes:

    • DISK_NAME durch den Namen des Bootlaufwerks
    • ZONE: die Zone des Laufwerks

    Die Ausgabe muss Folgendes enthalten, um das Bootlaufwerk mit einer Maschinenserie der dritten Generation zu verwenden:

    guestOsFeatures:
...
- type: GVNIC
- type: WINDOWS

  2. Beenden Sie die VM, die Sie bearbeiten möchten.

  3. Bootlaufwerk der VM trennen

  4. Verwenden Sie die Google Cloud Console, um eine Windows-VM mit den folgenden Attributen zu erstellen:

    • Zone: dieselbe Zone wie die ursprüngliche VM
    • Bootlaufwerk: das Bootlaufwerk der ursprünglichen VM
    • Maschinenserie: Maschinenserie der dritten Generation

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

Eingeschränkte Bandbreite mit gVNIC unter Microsoft Windows mit C3- und C3D-VMs

Unter Windows-Betriebssystemen erreicht der gVNIC-Treiber nicht die dokumentierten Bandbreitenlimits. Der gVNIC-Treiber kann eine Netzwerkbandbreite von bis zu 85 Gbit/s auf C3- und C3D-VMs erreichen, die Microsoft Windows ausführen, und zwar sowohl für das Standardnetzwerk als auch für die Netzwerkleistung pro VM-Tier_1.

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 Leistungsverbesserungen werden ausgeführt.

Niedrigere IOPS-Leistung für Hyperdisk Extreme unter Microsoft Windows mit C3- und M3-VMs

Die Leistung von Hyperdisk Extreme ist auf Microsoft Windows-VMs derzeit begrenzt.

Die Leistungsverbesserungen werden ausgeführt.

Die Maschinentypen C3D 180 und 360-vCPU unterstützen keine Windows-Betriebssystem-Images

C3D-180-vCPU-Maschinentypen unterstützen die Betriebssystem-Images von Windows Server 2012 und 2016 nicht. C3D-VMs, die mit 180 vCPUs und Windows Server 2012- und 2016-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.

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.

Allgemeiner Laufwerkfehler auf Windows Server 2016- und 2012 R2 für M3-, C3- und C3D-VMs

Das Hinzufügen oder Ändern der Größe einer Hyperdisk oder eines nichtflüchtigen Speichers für eine laufende M3- C3- oder C3D-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- oder C3D-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.