vioscsi Fehler mit Event ID 129

[exitsys]

Hallo zusammen,
ich beobachte jetzt bei zwei verschiedenen Proxmox VE Umgebungen das folgende Verhalten:

Beim Backup erscheint der im Betreff genannte Event Log Eintrag massiv im Minutentakt.
Manchmal läuft die Maschine trotzdem ganz normal weiter.
Es kommt aber auch vor, dass die Maschine irgendwann nicht mehr richtig reagiert und dann nur noch eines hilft.
Die VM über die Shell zu killen.
Es werden im 2 Stunden Takt alle VMs auf dem PBS gesichert.
Eine Umgebung hat nur 2 VMs, die andere 4 VMs.
Allerdings scheint es bei beiden eine Gemeinsamkeit zu geben.
Der Fehler tritt bei beiden Umgebungen nur beim Fileserver auf der eine zweite Disk hat.
Dabei spielt es keine Rolle ob Daten auf der Disk sind oder nicht.
Der Fehler tritt aber auch nicht bei jedem Backup auf sondern nur sporadisch.
Manchmal ist dann kein richtiger Zugriff mehr auf die Fileshares möglich, die auf genau dieser Disk liegen.
Dann dauert es nicht mehr lange bis zum Bluescreen. Oder man merkt es sofort und muss aber auch die VM killen, weil sie dann schon nicht mehr über die Konsole bedienbar ist.

Kurz einige Eckdaten zur VM:
- Windows Server 2022 englisch

Ausgabe von qm config

agent: 1
balloon: 8192
bios: ovmf
boot: order=scsi0;ide0;ide2;net0
cores: 8
cpu: host
efidisk0: Data:vm-103-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
ide0: local:iso/virtio-win-0.1.240.iso,media=cdrom,size=612812K
ide2: local:iso/SW_DVD9_Win_Server_STD_CORE_2022__64Bit_English_DC_STD_MLF_X22-74290.ISO,media=cdrom,size=5420564K
machine: pc-q35-8.1
memory: 16384
meta: creation-qemu=8.1.2,ctime=1703680088
name: ENTFERNT
net0: virtio=BC:24:11:CE:59:76,bridge=vmbr0,firewall=1,tag=ENTFERNT
numa: 0
onboot: 1
ostype: win11
scsi0: Data:vm-103-disk-1,discard=on,iothread=1,size=120G,ssd=1
scsi1: Data:vm-103-disk-3,discard=on,iothread=1,size=500G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=ENTFERNT
sockets: 1
startup: order=2
tpmstate0: Data:vm-103-disk-2,size=4M,version=v2.0
vmgenid: 94dd905c-49da-495e-9bfb-ae92ba2807e6
[/ICODE]





Vielleicht hat jemand eine Idee wie man das Problem löst?
Scheint ja immer noch offen zu sein.
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/756

 

[cwt]

Welche Treiberversion bzw. VirtIO-ISO hast Du denn installiert? Es gab mal einen Fix, der aber in der .229-Version wieder auftauchte.

Und wie sieht der "Unterbau" (Laufwerke) im PVE für den Server aus?

 

[exitsys]

ZFS Raid 10 mit 6 PM883 1,9TB SSD
ide0: local:iso/virtio-win-0.1.240.iso,media=cdrom,size=612812K
also 0.1.240 ist installiert.
kannst du eine Quelle angeben wo das mit dem Fix beschrieben war? nur damit man mal nachlesen kann, was da der Grund war.
Danke

 

[cwt]

Hast Du diesen Thread mal verfolgt/gelesen? Der TE hatte auf 229 aktualisiert und ist auf 204 zurückgegangen.

https://forum.proxmox.com/threads/w...csi-warning-129-locking-up-data-drive.121936/

Auf Github gibt es noch diesen Thread:

https://github.com/virtio-win/kvm-guest-drivers-windows/issues/756

Da betrifft es sowohl storage mit Ceph als auch lokal. Trim & blocksizes scheint bei einigen zumindest ansatzweise der Grund zu sein.

 

[exitsys]

ja, das war alles schon in gewissem Maße bekannt. ich hab das, was die letzten Tage dazu kam, auch nochmal durchgelesen, aber nichts was hilft dabei...

 

[cwt]

Ist denn die Hardware auf beiden Hosts identisch? Oder gewisse Gemeinsamkeiten (SSDs, Board, HBA) beim Storage? Was spuckt denn das Log auf den PVEs zu diesem Zeitpunkt aus?

 

[exitsys]

Moin, ja sind beides HP Proliant DL360 Gen10 Server.
Beides sind VMs mit Server 2022.
Der eine ist ein auf deutsch installierter 2016 über In Place Upgrade auf 2022 gebracht.
Der andere frisch auf englisch installierter.
Ich hab gerade nochmal auf das eine System geschaut. da war der Fehler das letzte mal gestern früh um 08:14Uhr. Seit dem nicht mehr aufgetreten obwohl ja alle 2 Stunden ein Backup zum PBS läuft.
Im Log finde ich zu der Zeit nichts auffälliges.

 

[exitsys]

für Interessierte ist hier auch noch ein anderer Link wo das Problem mit Red Hat Mitarbeitern besprochen wird.
Eine Lösung ist dort auch noch nicht gefunden.
Bei ihren Kunden ist der Fehler bisher nicht aufgetreten. Scheinbar nur bei Proxmox Kunden, wenn ich das dort richtig deute.

https://github.com/virtio-win/kvm-guest-drivers-windows/issues/623

 

[Falk R.]

Mal ne kleine Frage, auf was sichert der PBS?

 

[exitsys]

auf ZFS Raidz1

 

[Falk R.]

auf ZFS Raidz1

Und dann am besten noch HDDs?
Kann es sein, das der I/O Delay auf dem PBS etwas erhöht ist?
Das Problem beim Snapshot Backup mit dem PBS ist, dass ein Write I/O der VM pausiert wird, bis der original Block gelesen wurde und auf dem PBS geschrieben wurde. Das kann genau zu diesen Effekten führen, wenn der PBS Storage zu langsam ist.

 

[exitsys]

Ja, SAS HDDs. Aber es ist kein IO Delay auf der PBS Maschine und an einem anderen PVE mit PBS in der selben Konstellation keine Probleme. Da sind aber auch kein Windows Vms mit einer zweiten Disk drauf. Und wie gesagt, auf der einen VM sind auf der zweiten Disk noch nicht mal Daten drauf.

 

[Falk R.]

Guck mal im Windows während des Backups wie die Disklatenzen aussehen. Eventuell ist es ja ein anderes Problem bei dir, aber mich würde es nicht wundern, wenn du die gleichen Probleme wie viele andere Leute hast. Übrigens haben Linux VMs dann auch schlechte Latenzen, meckern nur nicht so viel rum.

 

[exitsys]

jetzt z.B. habe ich den Fehler in einer völlig anderen VM die nur eine Disk mit 500GB hat.
Ausgelöst durch einen Snapshot inkl. RAM. Also nicht beim Backup mit PBS.
Die Maschine ist nicht mehr bedienbar.
Darunter liegt wie oben geschrieben ein ZFS Raid 10 mit 6 PM883 1,9TB SSD

completed saving the VM state in 27s, saved 8.04 GiB
snapshotting 'drive-scsi0' (Data:vm-104-disk-1)
snapshotting 'drive-efidisk0' (Data:vm-104-disk-0)
snapshotting 'drive-tpmstate0' (Data:vm-104-disk-2)
TASK OK

 

[Falk R.]

Wenn du den kompletten RAM Inhalt abziehst, kann die VM kurze Zeit einfrieren. Das ist normal.

 

[exitsys]

Der Snapshot war innerhalb kurzer Zeit fertig, erst 4 Minuten später war der Log Eintrag. und die VM hing. merkwürdig.

 

[Falk R.]

Dann liegt es ja nicht direkt am Snapshot. Wie ist denn die RAM Auslastung vom Host und wie ist der ZFS Arc konfiguriert?

 

[exitsys]

72% 182GB von 256GB
am ZFS hab ich bisher keine Änderungen vorgenommen. alles Default Werte also sollte 50% sein.