OMV VM - I/O error

[duschkopf]

Hi,

ich habe seit ein paar Tagen OMV OS in einer VM laufen. Zwei USB Festplatten sind durchgereicht. Nun kommen "plötzlich" beim kopieren von Daten
Fehler bzw. die VM wird sofort gestoppt. Im der kern.log Datei ist das einzige Indiz:

openmediavault kernel: [  743.712763] I/O error, dev sdc, sector 3029837056 op 0x0:(READ) flags 0x80700 phys_seg 212 prio class 2

Dann ist die VM aus tot. OK, Fehler im Dateisystem sind das Eine, I/O Fehler am USB das Andere, aber das sich das system direkt zerschießt?

Hat jemand eine Idee?

beste Grüße

 

[Dunuin]

Hat jemand eine Idee?

Mal mit smartctl -t long /dev/DeineDisk am PVE Host einen Selbsttest der Disk anstoßen. Und die Disk-Controller der USB-Disks sind oft echt nicht zuverlässig...

 

[duschkopf]

ich habe die tests mal auf beiden Platten gestartet, allerdings vom OMV container aus, da ich da Zugriff auf die durchgereichten USB Platten habe und diese als /dev/sdb und /dev/sdc gemounted sind.
Was mich irritiert: In meiner log Ausgabe im ersten Post steht "I/O error, dev sdc". Ist damit /dev/sdc gemeint? Wenn ja, dann macht das keinen Sinn, denn die Platte bei der die Maschine crasht ist /dev/sdb und nicht sdc.

Update: Ich frage mich ob das hier was damit zu tu haben könnte, aber dann müsste das Problem doch häufiger vorkommen:
https://forum.proxmox.com/threads/vm-i-o-errors-on-all-disks.94259/post-433367

 

[Falk R.]

Eventuell ist die sdc des Host ja die sdb in der VM.

 

[sb-jw]

Zu dem angemerkten Thread, ich verwende immer nur VirtIO SCSI und hänge die als SCSI mit discard Flag ein. Hat bisher nie Probleme gemacht.
Insofern, probiert es halt einfach aus. Beachte nur, dass sich die interne Bezeichnung von vdX auf sdX ändern kann, bei neueren OS Versionen ist das in der Regel egal.

Ein mögliches Problem mit den USB Platten wird das aber auch nicht lösen.

 

[duschkopf]

Die Platten sind OK, liefen vorhe ohne Probleme. Sie hängen erst seit dem WE an OMV in der VM und gestern ist es mir aufgefallen bei einer von beiden Platten.
Das schließt HW Probleme im Prinzip aus.

 

[sb-jw]

Das schließt HW Probleme im Prinzip aus.

Nein tut es nicht. Du kannst eine Komponente 100.000 Stunden testen, keiner garantiert dir, dass nicht bei 100.001 Stunde ein Fehler auftritt. Nur weil X gestern noch funktionierte, muss es heute nicht immer noch der Fall sein.
Gerade USB Platten können durch mechanische Einwirkung, falscher Lagerung oder Behandlung nachhaltige Schäden davon tragen. Siehe zuletzt auch die SanDisk SSDs die nach und nach mechanisches Schäden davon tragen.

Poste mal ein lsblk von deiner Node und deiner VM. Dann können wir auch besser sehen welche Platte als welche gekennzeichnet ist. Die o.g. Fehlermeldung stammt von der Node oder von der VM?

 

[Dunuin]

Waren die denn vorher 24/7 im Dauerbetrieb? Also meine USB HDDs sind als NAS richtig heiß geworden was ja auch nicht toll für die Haltbarkeit/Zuverlässigkeit ist. Habe ich dann irgendwann die Gehäuse geöffnet und unter den Ventilator gepackt.
Als NAS sollten die HDDs schon aktiv gekühlt sein.

 

[duschkopf]

Poste gleich den Output von lsblk
Die Fehlermeldung spuckt die OMV VM aus bevor sie sich verabschiedet.
Die Platte ist ca. 3 Monate alt und hing am Laptop dran. Kein Dauerbetrieb, war 99% der Zeit aus.
Keinerlei Probleme bis ich sie an den proxmox Mini PC gehängt habe vor 4 Tagen.
Deswegen muss ich logisch betrachtet erstmal beleuchten was sich geändert hat und das ist der Umzug von einem PC zum nächsten und von einem physikalischen Ort zum anderen.

Temperaturprobleme sind auch unwahrscheinlich, auch an OMV dran ist sie die meiste Zeit im Standby. Der letzte Test führte nach unter 30s zum Crash, so schnell kann sie nicht heiß werden. Hab unter 30°C ausgelesen, dir andere platte läuft deutlich wärmer.

Was mich aber am meisten irritiert:
Die VM wird Knallhart gestoppt. Wie könnte ein Fehler von einem USB device zum Totalausfall des Systems führen? Das lässt mich Grad start an entweder OMV oder der VM Lösung bzw. An der Kombination zweifeln.

 

[Dunuin]

Temperaturprobleme sind auch unwahrscheinlich, auch an OMV dran ist sie die meiste Zeit im Standby. Der letzte Test führte nach unter 30s zum Crash, so schnell kann sie nicht heiß werden. Hab unter 30°C ausgelesen, dir andere platte läuft deutlich wärmer.

Ja, bei mir mit deaktiviertem Spindown werden die gerne 45 Grad und im Sommer auch gerne mal über 50 Grad.

Temperaturprobleme sind auch unwahrscheinlich, auch an OMV dran ist sie die meiste Zeit im Standby. Der letzte Test führte nach unter 30s zum Crash, so schnell kann sie nicht heiß werden.

Mal doof gefragt...du hast die aber nicht gleichzeitig noch im PVE Host in Benutzung oder in verschiedene VMs per "qm set" durchgereicht?

 

[duschkopf]

an andere VMs nicht durchgereicht.

Beide Platten sind per CIFS gemounted im Host. Den share stellt die OMV VM zur Verfügung. In ein paar LXC Container ist der Share auch gemounted, allerdings nicht die problematische Platte, sondern die andere.

bin in ein paar Minuten an der Shell und kann Outputs Posten.

 

[duschkopf]

OMV VM:

root@openmediavault:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0    8G  0 disk
├─sda1   8:1    0    7G  0 part /
├─sda2   8:2    0    1K  0 part
└─sda5   8:5    0  975M  0 part [SWAP]
sdb      8:16   0  5,5T  0 disk
└─sdb1   8:17   0  5,5T  0 part /srv/dev-disk-by-uuid-0A32C0FD32C0EF2F
sdc      8:32   0  1,8T  0 disk
└─sdc1   8:33   0  1,8T  0 part /srv/dev-disk-by-uuid-015fbcd3-d869-47b7-a199-1f
sr0     11:0    1  898M  0 rom

host (nicht gemounted):

root@host1:~# lsblk
NAME                                                  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1                                               259:0    0 476.9G  0 disk
├─nvme0n1p1                                           259:1    0  1007K  0 part
├─nvme0n1p2                                           259:2    0     1G  0 part /boot/efi
└─nvme0n1p3                                           259:3    0 475.9G  0 part
  ├─pve-swap                                          253:0    0     8G  0 lvm  [SWAP]
  ├─pve-root                                          253:1    0    96G  0 lvm  /
  ├─pve-data_tmeta                                    253:2    0   3.6G  0 lvm 
  │ └─pve-data-tpool                                  253:4    0 348.8G  0 lvm 
  │   ├─pve-data                                      253:5    0 348.8G  1 lvm 
  │   ├─pve-vm--103--disk--0                          253:6    0     8G  0 lvm 
  │   ├─pve-vm--100--disk--0                          253:7    0    32G  0 lvm 
  │   ├─pve-vm--106--disk--0                          253:8    0     2G  0 lvm 
  │   ├─pve-vm--107--disk--0                          253:9    0     4G  0 lvm 
  │   ├─pve-vm--108--disk--0                          253:10   0    10G  0 lvm 
  │   ├─pve-vm--100--state--dc1                       253:11   0   4.5G  0 lvm 
  │   ├─pve-vm--103--state--dc1                       253:12   0   2.5G  0 lvm 
  │   ├─pve-vm--101--disk--0                          253:13   0     4M  0 lvm 
  │   ├─pve-vm--101--disk--1                          253:14   0    32G  0 lvm 
  │   ├─pve-vm--102--disk--0                          253:15   0     2G  0 lvm 
  │   ├─pve-vm--104--disk--0                          253:16   0     8G  0 lvm 
  │   ├─pve-vm--105--disk--0                          253:17   0     4G  0 lvm 
  │   ├─pve-vm--110--disk--0                          253:18   0     4G  0 lvm 
  │   ├─pve-vm--109--disk--0                          253:19   0   512M  0 lvm 
  │   ├─pve-vm--101--state--dc1                       253:20   0   8.5G  0 lvm 
  │   ├─pve-vm--101--state--dc2_ssl_deactivated       253:21   0   8.5G  0 lvm 
  │   ├─pve-vm--101--state--dc3_some_stuff_configured 253:22   0   8.5G  0 lvm 
  │   ├─pve-vm--101--state--dc4_esphome_new_sensors   253:23   0   8.5G  0 lvm 
  │   ├─pve-vm--101--state--dc5_updated_nodered       253:24   0   8.5G  0 lvm 
  │   ├─pve-vm--111--disk--0                          253:25   0     8G  0 lvm 
  │   └─pve-vm--112--disk--0                          253:26   0     8G  0 lvm 
  └─pve-data_tdata                                    253:3    0 348.8G  0 lvm 
    └─pve-data-tpool                                  253:4    0 348.8G  0 lvm 
      ├─pve-data                                      253:5    0 348.8G  1 lvm 
      ├─pve-vm--103--disk--0                          253:6    0     8G  0 lvm 
      ├─pve-vm--100--disk--0                          253:7    0    32G  0 lvm 
      ├─pve-vm--106--disk--0                          253:8    0     2G  0 lvm 
      ├─pve-vm--107--disk--0                          253:9    0     4G  0 lvm 
      ├─pve-vm--108--disk--0                          253:10   0    10G  0 lvm 
      ├─pve-vm--100--state--dc1                       253:11   0   4.5G  0 lvm 
      ├─pve-vm--103--state--dc1                       253:12   0   2.5G  0 lvm 
      ├─pve-vm--101--disk--0                          253:13   0     4M  0 lvm 
      ├─pve-vm--101--disk--1                          253:14   0    32G  0 lvm 
      ├─pve-vm--102--disk--0                          253:15   0     2G  0 lvm 
      ├─pve-vm--104--disk--0                          253:16   0     8G  0 lvm 
      ├─pve-vm--105--disk--0                          253:17   0     4G  0 lvm 
      ├─pve-vm--110--disk--0                          253:18   0     4G  0 lvm 
      ├─pve-vm--109--disk--0                          253:19   0   512M  0 lvm 
      ├─pve-vm--101--state--dc1                       253:20   0   8.5G  0 lvm 
      ├─pve-vm--101--state--dc2_ssl_deactivated       253:21   0   8.5G  0 lvm 
      ├─pve-vm--101--state--dc3_some_stuff_configured 253:22   0   8.5G  0 lvm 
      ├─pve-vm--101--state--dc4_esphome_new_sensors   253:23   0   8.5G  0 lvm 
      ├─pve-vm--101--state--dc5_updated_nodered       253:24   0   8.5G  0 lvm 
      ├─pve-vm--111--disk--0                          253:25   0     8G  0 lvm 
      └─pve-vm--112--disk--0                          253:26   0     8G  0 lvm

 

[Falk R.]

Mal einen anderen USB Port probiert? Z.B. bei den Minisforum gibts Probleme mit einigen USB Ports.

 

[sb-jw]

Du sagst, dass es keinen Sinn machen würde, dass /dev/sdc einen Fehler hat, weil /dev/sdb crashen würde. Mir erschließt sich aus dem bisherigen Verlauf aber nicht, woran du fest machst, dass /dev/sdb das Problem ist. Wir sehen hier ein Problem mit /dev/sdc, welche offensichtlich die 1,8 TB Platte ist.

Was du uns bisher auch nicht geliefert hast ist der SMART Output von den beiden Platten.

 

[duschkopf]

/dev/sdb ist die Platte bei der es beim file transfer crasht. Reproduzierbar, bis jetzt. Der letzte output bevor die vm crasht (erster post) spuckt aber "dev sdc" aus. Das ist das Verwirrende.

SMART "extended information" aus OMV sind angehängt.

Ich habe den long test gestartet, ist aber noch nicht durch. Allerding hätte er auf der anderen Platte schon gegen 10 Uhr fertig sein müssen und da hab ich auch noch keine AUsgabe in OMV.

 

[sb-jw]

Also die 6 TB Platte würde ich als unauffällig bezeichnen. Einzig die SMART Infos scheinen dort nicht so recht anzukommen, das würde ich aber mal auf das Gehäuse schieben, nicht alle geben die Platte so 1:1 durch. Aber die eigentlichen Werte sehen für mich in Ordnung aus.

Wenn die andere noch immer dran ist, könnte das zu denken geben. Vorschlagsweise brech den Test mal ab und mach einfach nur ein "smartctl -a" und schick mal den Output durch. In der Regel lassen sich an den üblichen Werten auch bereits Fehler erkennen, weshalb ein langer Test nicht unbedingt nötig ist.

Was aber an der 6 TB Platte auf jeden Fall zu beanstanden ist, es ist eine SMR und keine CMR Platte, das kostet Performance - ich würde solche Platten aus Prinzip nicht verwenden. Womöglich könnte das auch ein Problem sein, dass die Platte hier einfach zu lange braucht um zu antworten.

Der recht hohe Start / Stop Count deutet auch daraufhin, dass sich die Platte womöglich zwischendurch abschaltet und in den Energiesparmodus geht. Das kann natürlich auch zu Problemen führen, da das OS vermutlich auch erwartet, dass die Platte da ist. Durch die Anlaufzeit entsteht auch hier eine erhöhte Antwortzeit was halt ebenfalls zu einem solchen Verhalten führen könnte.

Mit was für einem FS läufen die beiden Platten? Wie @Falk R. erwähnte, mal nen anderen USB Port probiert?

 

[duschkopf]

smartctl -a für beide Platten ist angehängt.

Ich werde einen anderen port probieren sobald der Fehler wiederkommt. Habe zum Testen wiede wild Dateien kopiert und es ist nichts passiert.

Das mit den start/stop count ist interessant. Seitdem die Platte an OMV hängt muss ich sie sehr oft wieder aus dem standby und das dauert bei der Platte echt lange.
Überlege grad dieses Test vorzuziehen, also im OMV die standby Zeit hoch stellen bzw. erstmal ausschalten. Wäre das sinnvoll?

Die "problematische" hat NTFS...
die kleinere die keine Probleme macht EXT4.
Ich hab das einfach mal verworfen am Anfang als mögliche Ursache weil ich keine Probleme mit NTFS unter Limnux hatte in den letzten Jahren und dachte das Thema wäre endlich durch

 

[duschkopf]

das wäre mal ein Versuch. Default steht alles auf disabled und ist sehr aggressiv beim spindown/standby.

 

[sb-jw]

Schau mal am Ende von deinem smart output, deine 2 TB Platte hat schon länger Probleme und auch 238 bei "UDMA_CRC_Error_Count". Das deutet auf eine mögliche defekte Verbindung oder Platte hin.

Probiere es so mal aus, dann siehst du ja ob es das Problem womöglich beseitigt. Ist jetzt natürlich so, dass durch die Einstellung auch beide Platten so 5 - 10 W an Strom ziehen werden. Vielleicht solltest du den Wechsel zu SSDs mal in Betracht ziehen, das spart Strom, Abwärme und gibt dir zusätzliche Performance.

 

[duschkopf]

Schau mal am Ende von deinem smart output, deine 2 TB Platte hat schon länger Probleme und auch 238 bei "UDMA_CRC_Error_Count". Das deutet auf eine mögliche defekte Verbindung oder Platte hin.

OK danke. Mist, ja die Platte ist schon etwas älter. Da ist auch deswegen nichts drauf, das wichtig wäre.

Ja der Stromverbauch wäre schon ein Problem, auch die Lautstärke zum teil. Bin da sehr empfindlich.
SSDs sind mir in der > 5GB Kategorie einfach noch zu teuer.

Ich beobachte das mal weiter. Die spindown time kann man ja auf einen brauchbaren Wert setzen, falls es überhaupt das Problems ein sollte. Default war das Teil nur am Hoch und Runterfahren. Meine Hoffnung ist aktuell der Punkt.
Falls nicht, dann eventuell Überhitzung vom miniPC. Da lief "kurz" vor dem ersten fail noch viel media transcoding, library scanning etc. von Plex drauf. Allerdings mit der Platte eingebunden, die keine Probleme gemacht hat. Wollte nur damit verdeutlichen, dass das System heiß war und sehr lange im 95°C Bereich mit maximaler Lüftung an war.
Ich will nicht an mehreren Stellschrauben gleichzeitig drehen, deswegen erstmal Versuch 1#: Spindown deaktiviert. Versuch 2#: USB Port wechseln und Versuch 3#: Bessere Lüftung für den miniPC.

Update: Da ich es aktuell nicht mehr reproduzieren kann, könnte ich natürlich auch einen Stresstest machen um das System 1. aufzuheizen und 2. Weitere I/O Last jeglicher Art generieren. Entweder mit Plex und/oder dem "stress" tool.

Update2: Kein Fehler, jedoch hat die Platte sich trotz der oberen stnadby settings nach ein paar Minuten runtergefahren...