storahci Fehler in virtuellen Windows Servern jeden Samstag

A

Aurisch

New Member
Proxmox Subscriber
Jul 28, 2025
10
4
3
Auf meinem Proxmox VE Host laufen 10 virtuelle Server, davon 9 Windows Server. Jeden Samstag zur selben Zeit (ca. 06:40) beginnend und ca. 24 Stunden anhaltend verliere ich zeitweise die Verbindung zu den virtuellen Servern. Im Ereignisprotokoll der virtuellen Server finde ich dann "storahci" Fehler mit der ID 129 folgend von "Disk" Fehler mit der ID 153. Die virtuellen Server laufen allesamt auf einem lokalen Storage des Hosts und das ist als ZFS formatiert. Im Systemprotokoll des Hosts finde ich zu dieser Zeit keinerlei diesbezügliche Einträge. Zu der Zeit in der die Fehler auftreten läuft auch keine Datensicherung.
Nach diesen 24 Stunden kommen auf den virtuellen Servern keinerlei Fehlermeldungen mehr - bis zum nächsten Samstag.
Die Fehlermeldungen in den virtuellen Servern treten zwar alle im gleichen Zeitraum (Samstag 06:40 Uhr -Sonntag 07:40 Uhr) auf, aber nicht zu genau der gleichen Zeit.
Ein Netzwerkproblem schließe ich mal aus, es deutet alles eher auf ein Speicherproblem hin, oder ? Der Host ist quasi neu und läuft erst seit 2,5 Monaten. Die virtuellen Server liefen vorher auf einem vmware Host und wurden importiert.
Jemand eine Idee ?
Heute angepasst: Systemzeit ging 1h vor, chrony konfiguriert und Zeitserver eingetragen. Jetzt passt die Zeit.
Ergänzung: Im Systemprotokoll gibt es doch Einträge: z.B.
VM 100 qmp command 'query proxmox-support' failed - got timeout.
 
Last edited:
Klingt nach einer Überlastung des ZFS. So klingt zumindest der Fehler innerhalb von Windows. Scrub default timer laufen default Samstags um 6 Uhr, das würde zeitlich gut passen.

Überprüfe mal mit

Bash: 
systemctl list-timers | grep scrub

wann der letzte Scrub war.

Laufen zu der Zeit auch ggf. Backups? Oder trim commands?
 
Check mal die Windows VMs ob die eventuell auch noch ihre Defragmentierung laufen lassen. Das ist auch ein Storagekiller.
 
cwt said:
Klingt nach einer Überlastung des ZFS. So klingt zumindest der Fehler innerhalb von Windows. Scrub default timer laufen default Samstags um 6 Uhr, das würde zeitlich gut passen.

Überprüfe mal mit

Bash: 
systemctl list-timers | grep scrub

wann der letzte Scrub war.

Laufen zu der Zeit auch ggf. Backups? Oder trim commands?
Click to expand...
1753767646670.png
Das sieht nicht danach aus. Scrub lief danach erst Sonnstag ab 03:11 Uhr.
Backups laufen vorher, sprich Samstags um 10:00 Uhr und waren bevor die Probleme anfingen fertig.
 
Als Blech dahinter steht übrigens ein SM Server mit 1 AMD EPYC 9375F und 128GB RAM. Als Platten sind NVMe SSDs drin. Das sollte für die Kiste eigentlich kein Problem darstellen. Ich hab mir mal die restlichen Timer angesehen. Zu der Zeit läuft nur der apt-daily-upgrader und der braucht keine 24h.
 
Last edited:
Sind das denn auch Enterprise NVME?
Laufen denn innerhalb der VMs ggf. Tasks zu diesem Zeitpunkt?
 
cwt said:
Sind das denn auch Enterprise NVME?
Laufen denn innerhalb der VMs ggf. Tasks zu diesem Zeitpunkt?
Click to expand...
SSD: PNY XLR8 CS3140 8TB im Raid1 auf einem AOC-SLG4-2H8M2 (Broadcom 3808)
Auf den Servern läuft zu der Zeit nichts was nicht in der Woche auch läuft.
 
Last edited:
Du kannst gern auch gebrauchte Enterprise SSDs nutzen, aber Enterprise sollten es schon sein.
Wenn neu, dann mag ich die Huawei U.2 NVMe, da hast du ein spitzen Preis/Leistungsverhältnis.
 
Es fällt mir schwer zu glauben, dass die Consumer-SSDs hier die Ursache sein sollen. Wenn mehr als zwei verbaut wären, könnte ich das vielleicht akzeptieren (wenn ein Raid 5 beispielsweise neu aufgebaut werden würde), aber nicht bei einem Raid 1.

@ TE: Hardware-Raid oder per Software, z.B, via ZFS?

(Nichtsdestotrotz sind die SSDs sehr schlecht ausgewählt...)
 
In den NVME sitzt der Phison E18 controller. Der hat so seine Macken und neigt zu unvorhersehbaren I/O-Latenzen bei Lastspitzen im parallelen Zugriff. Windows kann das dann als „hängendes Gerät“ interpretieren.
 
  • Like
Reactions: Johannes S and GMBauer
Mario Hosse said:
Läuft der AOC-SLG4-2H8M2 im IT-Mode?
Click to expand...
Vergesst mal eure Fragen nach dem IT-Mode. Das interessiert bei aktuellen Controllern nicht mehr und der kann entweder Raid1 oder HBA Mode.
Bei allen einigermaßen aktuellen Modellen kann man das umstellen ohne das Umflashen, was auch mal schief gehen kann.
 
  • Like
Reactions: ThoSo and Johannes S
Falk R. said:
Vergesst mal eure Fragen nach dem IT-Mode. Das interessiert bei aktuellen Controllern nicht mehr und der kann entweder Raid1 oder HBA Mode.
Bei allen einigermaßen aktuellen Modellen kann man das umstellen ohne das Umflashen, was auch mal schief gehen kann.
Click to expand...
Naja, er schreibt ja 2x 8TB im Raid1 auf dem Controller. Umstellen kann man diesen Controller nicht. Wir wissen nicht wie ZFS aufgesetzt wurde und ich habe mit ZFS auch keine Erfahrung. So müsste er erklären, welche ZFS-Konfiguration er aufgesetzt hat.

Die Empfehlung für ZFS ist doch bei dieser Konstellation jede Platte als Raid0 im Controller zu konfigurieren und diese dann ins ZFS aufzunehmen, damit ZFS diese Platten verwalten kann? Korrigiert mich bitte, falls ich falsch liege!

Lösungen wären also:
a) ZFS anpassen

oder

c) Eine Umstellung des Controllers in den IT-Mode, wäre nur auf eigene Gefahr durch flashen möglich mit:
Supermicro IT-Mode 3808

oder

d) Er könnte auch beide NVME direkt auf das Mainboard nehmen und ZFS aufsetzen.
 
Wie der Controller konfiguriert ist wissen wir nicht. Raid0 wäre die schlechteste Option. Man kann auch diesen Controller im BIOS zwischen RAID oder HBA Mode umstellen, auch ohne dem Umflashen.
Man muss nur wissen, dass die Daten verloren gehen, wenn man zwischen HBA und RAID Mode wechselt. Also bitte nicht Umflashen was schief gehen kann sondern einfach Raids löschen und HBA Mode nutzen.
 
  • Like
Reactions: UdoB
You must log in or register to reply here.
Top Bottom