Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei NVMe-Laufwerken
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In diesem Dokument werden Fehler aufgeführt, die bei der Verwendung von Laufwerken mit der NVMe-Schnittstelle (Persistent Express) auftreten können.

Sie können die NVMe-Schnittstelle für lokale SSDs und nichtflüchtige Speicher (Persistent Disk oder Google Cloud Hyperdisk) verwenden. Nur die neuesten Maschinenserien wie Tau T2A, M3, C3, C3D und H3 verwenden die NVMe-Schnittstelle für nichtflüchtige Speicher. Confidential VMs verwenden auch NVMe for Persistent Disk. Alle anderen Compute Engine-Maschinen verwenden die SCSI-Laufwerksschnittstelle für nichtflüchtige Speicher.

E/A-Vorgangszeitüberschreitungsfehler

Wenn E/A-Zeitüberschreitungsfehler auftreten, kann die Latenz den Standardzeitüberschreitungsparameter für E/A-Vorgänge überschreiten, die an NVMe-Geräte gesendet werden.

Fehlermeldung:

[1369407.045521] nvme nvme0: I/O 252 QID 2 timeout, aborting
[1369407.050941] nvme nvme0: I/O 253 QID 2 timeout, aborting
[1369407.056354] nvme nvme0: I/O 254 QID 2 timeout, aborting
[1369407.061766] nvme nvme0: I/O 255 QID 2 timeout, aborting
[1369407.067168] nvme nvme0: I/O 256 QID 2 timeout, aborting
[1369407.072583] nvme nvme0: I/O 257 QID 2 timeout, aborting
[1369407.077987] nvme nvme0: I/O 258 QID 2 timeout, aborting
[1369407.083395] nvme nvme0: I/O 259 QID 2 timeout, aborting
[1369407.088802] nvme nvme0: I/O 260 QID 2 timeout, aborting
...

Lösung:

Erhöhen Sie den Wert des Zeitüberschreitungsparameters, um dieses Problem zu beheben.

Rufen Sie den aktuellen Wert des Zeitüberschreitungsparameters auf.
1. Bestimmen Sie, welcher NVMe-Controller vom nichtflüchtigen Speicher oder der lokalen SSD verwendet wird.
```
ls -l /dev/disk/by-id
```
2. Rufen Sie die in Sekunden angegebene Einstellung io_timeout für das Laufwerk auf.
```
cat /sys/class/nvme/CONTROLLER_ID/NAMESPACE/queue/io_timeout
```
  Ersetzen Sie Folgendes:
  - CONTROLLER_ID: die ID des NVMe-Disk-Controllers, z. B. nvme1
  - NAMESPACE: der Namespace des NVMe-Laufwerks, z. B. nvme1n1
  Wenn Sie nur ein Laufwerk mit NVMe verwenden, verwenden Sie den Befehl:
```
cat /sys/class/nvme/nvme0/nvme0n1/queue/io_timeout
```
Um den Zeitüberschreitungsparameter für E/A-Vorgänge zu erhöhen, die an NVMe-Geräte gesendet wurden, fügen Sie der Datei /lib/udev/rules.d/65-gce-disk-naming.rules die folgende Zeile hinzu und starten Sie dann die VM neu:
```
KERNEL=="nvme*n*", ENV{DEVTYPE}=="disk", ATTRS{model}=="nvme_card-pd", ATTR{queue/io_timeout}="4294967295"
```

Getrennte Laufwerke werden weiterhin im Betriebssystem einer Compute-Instanz angezeigt

Auf VMs mit der Linux-Kernelversion 6.0 bis 6.2 funktionieren Vorgänge, die die Compute Engine API-Methode instances.detachDisk oder den Befehl gcloud compute instances detach-disk umfassen, möglicherweise nicht wie erwartet. In der Google Cloud Console wird das Gerät als entfernt angezeigt. In den Metadaten der Compute-Instanz (compute disks describe-Befehl) wird das Gerät ebenfalls als entfernt angezeigt. Der Bereitstellungspunkt des Geräts und alle von udev-Regeln erstellten Symlinks sind jedoch weiterhin im Gastbetriebssystem sichtbar.

Fehlermeldung:

Der Versuch, von dem getrennten Laufwerk in der VM zu lesen, führt zu I/O-Fehlern:

sudo head /dev/nvme0n3

head: error reading '/dev/nvme0n3': Input/output error

Problem:

Bei Betriebssystem-Images, die einen Linux-Kernel 6.0–6.2 verwenden, aber keinen Backport eines NVMe-Fixes enthalten, wird nicht erkannt, wenn ein NVMe-Laufwerk getrennt wurde.

Lösung:

Starten Sie die VM neu, um das Entfernen des Laufwerks abzuschließen.

Verwenden Sie ein Betriebssystem mit einer Linux-Kernelversion, bei der dieses Problem nicht auftritt, um dieses Problem zu vermeiden:

5.19 oder älter
6.3 oder höher

Mit dem Befehl uname -r im Gastbetriebssystem können Sie die Linux-Kernelversion aufrufen.

Symlinks, die nicht auf C3- und C3D-VMs mit lokaler SSD erstellt wurden

Wenn Sie lokale SSD-Laufwerke an eine C3- oder C3D-VM anhängen, müssen Sie möglicherweise zusätzliche Schritte ausführen, um die Symlinks für die lokalen SSD-Laufwerke zu erstellen. Diese Schritte sind nur erforderlich, wenn Sie eines der folgenden öffentlichen Images vonGoogle Cloudverwenden:

SLES 15 SP4 und SP5
SLES 12 SP4

Diese zusätzlichen Schritte gelten nur für lokale SSDs. Bei Persistent Disk-Volumes müssen Sie nichts weiter tun.

Die oben aufgeführten öffentlichen Linux-Images haben nicht die richtige udev-Konfiguration, um Symlinks für lokale SSD-Geräte zu erstellen, die an C3- und C3D-VMs angehängt sind. Benutzerdefinierte Images enthalten möglicherweise auch nicht die erforderlichen udev-Regeln, die zum Erstellen von Symlinks für lokale SSD-Geräte erforderlich sind, die an C3- und C3D-VMs angehängt sind.

Verwenden Sie diese Anleitung, um udev-Regeln für SUSE- oder benutzerdefinierte Images hinzuzufügen.

Suchen Sie das udev-Regelverzeichnis. Dies ist normalerweise /lib/udev/rules.d oder /usr/lib/udev/rules.d. Ihr Image hat möglicherweise ein anderes udev-Regelnverzeichnis.
Suchen Sie im udev-Regelverzeichnis die Datei 65-gce-disk-naming.rules.
Wenn die 65-gce-disk-naming.rules-Datei die folgende Zeile enthält, unterstützt Ihr Bild die neuen Regeln und Sie können mit der weiteren Bearbeitung fortfahren:
```
KERNEL=="nvme*n*", ATTRS{model}=="nvme_card[0-9]*",IMPORT{program}="google_nvme_id -d $tempnode"
```
Wenn die vorherige Zeile oder die Datei 65-gce-disk-naming.rules nicht vorhanden ist, ersetzen Sie die vorhandene Datei oder erstellen Sie eine neue Datei mit dem Dateiinhalt von dieser URL: https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/rules.d/65-gce-disk-naming.rules Diese Datei enthält den aktualisierten Inhalt der Datei 65-gce-disk-naming.rules, einschließlich der Zeile aus dem vorherigen Schritt und anderer Regeln, die für die Benennung von Compute Engine-Laufwerken erforderlich sind. Beispiele:
```
sudo curl -o 65-gce-disk-naming.rules https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/rules.d/65-gce-disk-naming.rules
```
Wechseln Sie in das Verzeichnis udev.
Suchen Sie im Verzeichnis udev nach der Datei google_nvme_id.

Ersetzen Sie den Inhalt der vorhandenen google_nvme_id-Datei oder erstellen Sie eine neue Datei mit dem Inhalt dieser URL:

sudo curl -o google_nvme_id https://raw.githubusercontent.com/GoogleCloudPlatform/guest-configs/20230630.00/src/lib/udev/google_nvme_id

Die Datei google_nvme_id muss ausführbar sein.
```
sudo chmod 755 google_nvme_id
```
Starten Sie die VM neu.
Prüfen Sie, ob die Symlinks erfolgreich erstellt wurden.
```
ls -l /dev/disk/by-id/google-local-nvme-ssd*
```
Die Ausgabe sollte die gleiche Anzahl von Links auflisten wie lokale SSDs, die mit der Instanz verbunden sind, und jeder Link sollte auf einen anderen /dev/nvme-Gerätepfad verweisen. Beispiele:
```
lrwxrwxrwx 1 root root 13 Jul 19 22:52 /dev/disk/by-id/google-local-nvme-ssd-0 -> ../../nvme0n1
lrwxrwxrwx 1 root root 13 Jul 19 22:52 /dev/disk/by-id/google-local-nvme-ssd-1 -> ../../nvme1n1
```
Weitere Informationen zu Gerätenamen finden Sie unter Gerätenamen.

Sie können mit lsblk prüfen, ob die /dev/nvme-Gerätepfade lokale SSDs sind. NVMe-Geräte mit der Größe 375G sind lokale SSDs.

Nächste Schritte

Weitere Informationen zu nichtflüchtigen Speichern.
Weitere Informationen zu lokalen SSDs.
Laufwerke so konfigurieren, dass sie die Leistungsanforderungen erfüllen.
Weitere Informationen zu Symlinks.