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

Allgemeine Probleme

Die folgenden Probleme enthalten Anleitungen zur Fehlerbehebung oder allgemeine Informationen.

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

Wenn nach einem Hostfehler, durch den eine Instanz auf einen neuen Host verschoben wurde, der Metadatenserver abgefragt wird, werden möglicherweise die physicalHost-Metadaten des vorherigen Hosts der Instanz angezeigt.

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

  • Verwenden Sie die Methode instances.get oder den Befehl gcloud compute instances describe, um die richtigen physicalHost-Informationen abzurufen.
  • Beenden und dann starten Sie die Instanz. Dabei werden die physicalHost-Informationen auf dem Metadatenserver aktualisiert.
  • Warten Sie 24 Stunden, bis die physicalHost-Informationen der betroffenen Instanz aktualisiert wurden.

Nur IPv6-fähige C3-VM ist während der Live-Migration nicht erreichbar

Eine nur IPv6-fähige VM, die einen C3-Maschinentyp verwendet, kann während der Livemigration unerreichbar werden.

Workaround:

Um die Wahrscheinlichkeit zu verringern, dass dieses Problem auftritt, können Sie die Wartungsrichtlinie für die Instanz aktualisieren und das Wartungsverhalten auf TERMINATE und den automatischen Neustart auf TRUE festlegen.

Wenn Ihre VM eine Live-Migration durchläuft und dieses Problem auftritt, starten Sie die VM neu, um wieder auf die Instanz zugreifen zu können.

Lange baseInstanceName-Werte in verwalteten Instanzgruppen (MIGs) können zu Laufwerksnamenskonflikten führen

In einer MIG können Konflikte bei Laufwerknamen auftreten, wenn in der Instanzvorlage Laufwerke angegeben sind, die beim Erstellen der VM erstellt werden sollen, und der Wert für baseInstanceName mehr als 54 Zeichen hat. Das liegt daran, dass Compute Engine Laufwerknamen mit dem Instanznamen als Präfix generiert.

Wenn beim Generieren von Laufwerknamen der resultierende Name die maximale Länge von 63 Zeichen überschreitet, werden die überzähligen Zeichen am Ende des Instanznamens von der Compute Engine abgeschnitten. Das kann dazu führen, dass identische Laufwerknamen für Instanzen mit ähnlichen Benennungsmustern erstellt werden. In diesem Fall versucht die neue Instanz, das vorhandene Laufwerk anzuhängen. Wenn das Laufwerk bereits an eine andere Instanz angehängt ist, schlägt das Erstellen 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 Datenbeschädigungen führen kann.

Um Konflikte bei Laufwerknamen zu vermeiden, darf der Wert für baseInstanceName maximal 54 Zeichen lang sein.

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

Wenn Sie eine Instanzvorlage verwenden, die einen A2-, C3- oder G2-Maschinentyp angibt, um eine Reservierung zu erstellen oder eine Anfrage für eine zukünftige Reservierung zu erstellen und zur Überprüfung einzureichen, treten Probleme auf. Zum Beispiel:

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

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

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

  • Das Erstellen der Anfrage für eine vorausschauende Reservierung war erfolgreich. Wenn Sie ihn jedoch zur Überprüfung einreichen, lehnt Google Cloud Ihren Antrag ab.

Sie können die Instanzvorlage, die zum Erstellen einer Reservierung oder einer 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, gehen Sie stattdessen so vor:

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 Laufwerksnummer nicht übereinstimmt, wird von der Compute Engine-Steuerungsebene ein Fehler bei der lokalen SSD-Fehlkonfiguration angezeigt. Im Dokument Maschinen für allgemeine Zwecke finden Sie Informationen dazu, wie Sie die richtige Anzahl lokaler SSD-Laufwerke basierend auf dem Maschinentyp C3 oder C3Dlssd auswählen.

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. Verwenden Sie mehrere TCP-Flows, um höhere Raten zu erzielen.

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.

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.

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.

SUSE Enterprise-VM kann nach dem Ändern des Instanztyps nicht gestartet werden

Nachdem Sie den Instanztyp einer SUSE Linux Enterprise-VM geändert haben, kann der Start fehlschlagen. 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 (initiales RAM-Dateisystem), das verschiedene Instanztypen unterstützt. Dazu werden die --no-hostonly --no-hostonly-cmdline -o multipath-Flags bei der erstmaligen Bilderstellung 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 einer kleineren initramfs, die speziell auf die Hardware des aktuellen Systems zugeschnitten ist und möglicherweise Treiber ausschließt, die für andere Instanztypen erforderlich sind.

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

Problemumgehung

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

dracut --force --no-hostonly

Wenn das System bereits vom Problem betroffen ist, erstellen Sie eine vorübergehende 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 mit SUSE 12-Images

Z3-VMs mit SUSE Linux Enterprise Server (SLES) 12-Images erreichen bei IOPS auf lokalen SSDs deutlich weniger als die erwartete Leistung.

Ursache

Dies ist ein Problem in der SLES 12-Codebasis.

Problemumgehung

Ein Patch von SUSE zur Behebung dieses Problems ist nicht verfügbar und auch nicht geplant. Stattdessen sollten Sie das Betriebssystem SLES 15 verwenden.

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, wird der Netzwerkzugriff beim Neustart möglicherweise unterbrochen. Das liegt daran, dass RHEL das Deaktivieren von vorhersehbaren 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.

Ö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 Aussetzen und Fortsetzen

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

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

Bei Windows-VMs in der Compute Engine, auf denen VirtIO-NICs ausgeführt werden, gibt es einen bekannten Fehler, bei dem bei der Messung der NTP-Abweichung Fehler auftreten, wenn der folgende Befehl verwendet wird:

w32tm /stripchart /computer:metadata.google.internal

Die Fehlermeldungen 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 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 Generation 1 oder 2 auf eine VM der Generation 3 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-Laufwerkschnittstelle verwendet, in eine neuere Maschinenserie mit einer NVMe-Laufwerkschnittstelle ändern möchten, führen Sie vor dem Herunterfahren der VM ein Windows-PnP-Treiber-Sysprep durch. Bei dieser Sysprep-Ausführung werden nur Gerätetreiber vorbereitet und sichergestellt, dass beim nächsten Start alle Laufwerkschnittstellentypen nach dem Bootlaufwerk gesucht werden.

So aktualisieren Sie die Maschinenreihe einer VM:

Führen Sie in 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 gestartet wird, ändern Sie die VM wieder in den ursprünglichen Maschinentyp zurück, damit sie wieder funktioniert. Der Dienst sollte jetzt gestartet werden. Prüfen Sie, ob Sie die Anforderungen für die Migration erfüllen. Wiederholen Sie dann die Anleitung.

Eingeschränkte Bandbreite mit gVNIC unter Windows-VMs

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

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

Begrenzte Anzahl von Laufwerken, die bei neueren VM-Maschinenreihen angehängt werden können

VMs, die unter Microsoft Windows mit der NVMe-Laufwerkschnittstelle ausgeführt werden (z. B. T2A, alle VMs der dritten Generation und neuer sowie VMs mit vertraulichem Computing), können maximal 16 Laufwerke binden. Um Fehler zu vermeiden, sollten Sie den Persistent Disk- und Hyperdisk-Speicher auf maximal 16 Laufwerke pro VM konsolidieren. Lokaler SSD-Speicher ist von diesem Problem ausgenommen.

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.

Es werden derzeit Leistungsverbesserungen durchgeführt.

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

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.