Defekte Dateisysteme unter deutschem Windows

Hallo zusammen,

vor einiger Zeit hatte ich folgenden Post geschrieben: https://forum.proxmox.com/threads/ständig-windows-vms-mit-kaputtem-filesystem.111640/

Die Kurzfassung ist, dass es ständig zu defekten Dateisystemen unter Windows mit SCSCI-VirtIO auf ZFS gekommen ist. Wir haben den Festplattendurchsatz eingeschränkt, um eine Überlastung von IO einzuschränken. Eigentlich ging ich davon aus, dass wir das Problem durch eine Reinstallation behoben haben. Leider war dem nicht so. Es kam weiter zu defekten Festplatten. Seltener, aber immer noch regelmäßig. Nach hohen IO-Lasten war immer mindestens eine virtuelle Festplatte defekt.

Es handelt sich um Windows VMs (2016 Server) q35-5.1, ursprünglich von einem Hypervisor von Windows portiert. Die Festplatten waren per VirtIO-SCSI eingebunden. Caches habe ich, wegen mangelnder Alternativen, alle systematisch durchprobiert. Ebenso wie alle anderen SCSI Einstellungen (Discard, io_threads,...). Daran liegt es nicht. Wir haben schlussendlich einen zweiten Server gekauft, um diverse Hardwareprobleme auszuschließen. Aber auch auf dem zweiten Server sind nach der Migration Festplatten bei hoher IO Last durch defekte Filesysteme ausgefallen. Ich bin mir also ziemlich sicher, dass es sich nicht um ein Hardwareproblem handelt. Da es in insgesamt 3 Proxmox (2 Server, eine Reinstallation) Installationen aufgetreten ist, gehe ich auch nicht von einer fehlerhaften Installation aus (alle wurden jeweils mit einem neu heruntergeladenem ISO installiert).

Auffällig war jedoch, dass eine der fünf VMs über die Zeit hinweg nur einen Fehler hatte, wogegen ich die anderen jeweils etwa 10x aus Backups wiederherstellen musste. Diese eine wurde mit englischem ISO installiert und hat statt einem q35-5.1 ein i440fx-6.1. Sie verwendet ebenfalls VirtIO-SCSI.

Zusammenfassung:
Eine VM - englisches Windows ISO i440fx-6.1 nur ein Fehler.
Drei VMs importiert von einem Hypervisor q35-5.1 - vermutlich ursprüngliches deutsches ISO - etwa 10 Fehler je VM über die Zeit hinweg.
Eine neu installierte Windows VM q35-5.1 deutsches ISO - etwa 10 Fehler über die Zeit hinweg.

Insgesamt also etwa 40x aus Backups wiederhergestellte Windows-Systeme. Der Kunde war also überhaupt nicht glücklich und ich entsprechend frustriert.

Ich habe also viele Tests in einer produktiven Umgebung durchgeführt. Besonders effizient konnte ich VMs mit Snapshot-Backups zerstören, was in der Kundenumgebung wirklich zu größeren Schäden geführt hat, weil das neue Backup dann meistens ebenfalls defekt war und ich immer 2 Tage zurücksetzen musste. Ich vermute vom generellen Ablauf und meinen Analysen einen Zusammenhang mit dem fs-freeze und fs-thaw beim Erstellen der Snapshots für neue Backups. Sicher bin ich aber nicht. Auch normale IO Last konnte die Dateisysteme zerstören (z.B. ein Export aus einer Datenbank, ein Windows-Update oder ähnliches).

Ich bin mir aber relativ sicher, dass es mit den SCSI-Treibern und dem deutschen Windows zusammenhängt. Bedenkt man die generellen Probleme mit VirtIO und dem deutschen Windows, würde ich hier weitere Probleme nicht ausschließen. Die Alternative wäre, dass es mit dem q35 gegenüber i440fx zusammenhängt. Sicher ist, es hat mit SCSI zu tun. Denn final konnte ich das Problem lösen, indem ich alle Festplatten auf SATA umgestellt habe. Hier habe ich auch ein wenig mit Caches experimentiert, keine Probleme. Wäre SCSI nicht in den Empfehlungen für Windows-Installationen gestanden, hätte ich viel früher auf SATA umgestellt und dem Kunden und mir sehr viel Leid erspart.

Ich wollte diesen Erfahrungsbericht mit euch teilen und hoffe, ich kann einige andere Nutzer vor diesen Problemen bewahren. Mich würde brennend interessieren, ob andere dieses Phänomen kennen oder sogar nachstellen können? Ich finde es ziemlich seltsam, dass es dazu nicht mehr Einträge gibt. Erklären kann ich mir das nur damit, dass Installationen mit deutschem ISO sowieso nur bis q35-5.1 funktionieren. Wer neuere q35 verwendet, scheitert ja bereits bei der Installation.

Ich bin gespannt auf eure Meinungen. :)
 
Vielleicht sollte man in den Best Practice bis auf weiteres für "german" ISO von Windows q35-5.1 empfehlen sowie ältere VirtIO Treiber.
Irgendwann wir das sicher gelöst werden. Bis dahin alternativ halt eng-ISO mit DE-Lang-Pack. Machen wir hier schon lange so.
 
  • Like
Reactions: christian-b
stell mal betroffene VMs auf "Virtio SCSI Single" um und aktiviere IO-Thread sowie "Threads" bei Async-IO

io_uring hat issues insbes. auf CIFS

Schau mal ob das was verändert.

Ohne diese Settings haben VMs bei hohem IO gerne mal schluckauf und ich kann mir vorstellen, daß das auch zu weiteren Folgeproblemen führt...

>Erklären kann ich mir das nur damit, dass Installationen mit deutschem ISO sowieso nur bis q35-5.1
>funktionieren. Wer neuere q35 verwendet, scheitert ja bereits bei der Installation.

Inwiefern? Wg. Netzwerk?
 
Last edited:
  • Like
Reactions: christian-b
>Auch hängt sich das DE-Windows bei >q35-5.1 gerne mal auf beim Installieren der VirtIO-Treiber.

d.h. das Windows friert komplett ein/stürzt ab? oder der installer bleibt hängen?
 
Ja, hat aber auch wenig mit dem eigentlichen Thema von defekten Filesystems zu tun. Ich hatte schon bezüglich des Bugs geklickt, aber festgestellt, dass ich keine Ahnung habe, wie man dort einen Bug meldet. Du kannst mir das gerne ein bisschen genauer erklären per Direkt-Nachricht, dann stelle ich einen Bug bei Microsoft.

>kannst du das zuverlässig vorführen/reproduzieren?

Reproduzieren ist ein wenig übertrieben. Ich kann zuverlässig einmal pro Woche (manchmal innerhalb eines Tages) eine VM in der produktiven Umgebung meines Kunden das Filesystem zerschießen lassen. Ich kann euch gerne das Setup beschreiben oder irgendwo nachstellen.
 
  • Like
Reactions: RolandK
In der Tat klingt dieser Bug sehr ähnlich zu meinem Problem. Ich hab aber nie überprüft, ob nur die Boot-Tabelle kaputt ist. Könnte aber sehr gut sein.
Anfangs hatte ich die Backups auch per Dump erstellt. Später dann per Proxmox-Backup-Server. Das Problem blieb aber bestehen, wurde nur seltener. Wie oben beschrieben ist das Setup einfach:

Die Installation ist nicht speziell:
DE-Windows-Server 2016, q35-5.1, SCSI Virt-IO auf einer ZFS Disk-Thin-Provision ansonsten Standard, Balloon, Guest-Service etc. installiert und dann während ein bisschen IO-Last ein Snapshot-Backup auslösen. Auf IDEs kann man es leichter replizieren, als auf SSDs. Cache egal, mit Write-Through passiert es gefühlt häufiger. Alle Disk-Einstellungen sind egal. Ich hab wie gesagt alle durchprobiert, weil ich dachte, es liegt daran. Ich habe 2 Server probiert. Einen AMD EPYC 7502P, einen Intel E5-2609. Der AMD hat 128 GB Ram, der Intel 64 GB Ram. ZFS hab ich mit Mirror, Single Disk, RAID-Z1, mit SSD und IDEs - ist auch egal.

Was braucht ihr noch?
 
vzdump full backup oder proxmox backup server?

die vm konfiguration bitte
und bitte mal prüfen ob wirklich die ganze VM fritte ist bzw. filesystem korrupt oder ob es das "partitionstabelle weg" problem ist
 
Bash:
# qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID       
       100 win-easytec          running    16384              0.00 1800726   
       101 win-swdc             running    8192               0.00 731286   
       103 win-swacadoro        running    8192               0.00 1445126   
       104 win-storage          running    8192               0.00 4119670   
       107 win-swwts2           running    48000            100.00 399382   

# cat /etc/pve/qemu-server/101.conf
agent: 1
balloon: 4096
bios: ovmf
boot: 
cores: 4
efidisk0: black:vm-101-disk-1,efitype=4m,pre-enrolled-keys=1,size=528K
machine: pc-q35-5.1
memory: 8192
meta: creation-qemu=6.1.0,ctime=1650010895
name: win-swdc
net0: virtio=9A:E3:46:45:25:6D,bridge=vmbr1,tag=4
numa: 0
onboot: 1
ostype: win10
sata0: black:vm-101-disk-2,cache=writeback,discard=on,mbps_rd=100,mbps_rd_max=100,mbps_wr=100,mbps_wr_max=100,size=128G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=81f3a221-27f6-47b6-b8b4-a0aa588940ad
sockets: 1
startup: order=1
vcpus: 4
vmgenid: 68ffb2b6-cdfc-4632-8ef8-b4e6bcb70d79
vmstatestorage: black


# cat /etc/pve/qemu-server/104.conf
agent: 1
balloon: 4096
bios: ovmf
boot: 
cores: 4
efidisk0: blue:vm-104-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
machine: pc-q35-5.1
memory: 8192
meta: creation-qemu=6.1.0,ctime=1650061916
name: win-storage
net0: virtio=5E:8D:C8:7A:EE:22,bridge=vmbr1,tag=4
numa: 0
onboot: 1
ostype: win10
sata0: black:vm-104-disk-1,cache=writeback,discard=on,mbps_rd=100,mbps_rd_max=100,mbps_wr=100,mbps_wr_max=100,size=350G,ssd=1
sata1: black:vm-104-disk-0,cache=writeback,discard=on,mbps_rd=100,mbps_rd_max=100,mbps_wr=100,mbps_wr_max=100,size=100G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=2d2653ca-7e6e-49ed-a3ad-6162d815a89d
sockets: 1
startup: order=2
vcpus: 4
vmgenid: 422da67f-de2b-4885-85e1-eb74ccd9186a
vmstatestorage: blue


# cat /etc/pve/qemu-server/100.conf
agent: 1
balloon: 12288
bios: ovmf
boot: order=ide2
cores: 16
efidisk0: black:vm-100-disk-3,efitype=4m,pre-enrolled-keys=1,size=528K
machine: pc-i440fx-6.1
memory: 16384
meta: creation-qemu=6.1.0,ctime=1649611567
name: win-easytec
net0: virtio=3A:28:28:13:F0:27,bridge=vmbr1,tag=4
numa: 0
onboot: 1
ostype: win10
scsi0: black:vm-100-disk-0,discard=on,mbps_rd=50,mbps_rd_max=50,mbps_wr=50,mbps_wr_max=50,size=64G,ssd=1
scsi1: black:vm-100-disk-1,discard=on,mbps_rd=30,mbps_rd_max=30,mbps_wr=30,mbps_wr_max=30,size=100G,ssd=1
scsi2: black:vm-100-disk-2,discard=on,mbps_rd=30,mbps_rd_max=30,mbps_wr=30,mbps_wr_max=30,size=50G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=71aa44fb-2cb2-4962-b078-a2e17ee338e4
sockets: 1
startup: order=2
vcpus: 16
vmgenid: 6c9b02f1-363a-44a5-bb2e-cbb4ac33b807
vmstatestorage: black


# cat /etc/pve/qemu-server/103.conf
agent: 1
balloon: 6144
bios: ovmf
boot: 
cores: 8
efidisk0: blue:vm-103-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
machine: pc-q35-5.1
memory: 8192
meta: creation-qemu=6.1.0,ctime=1650033366
name: win-swacadoro
net0: virtio=4E:7D:08:C0:7C:CF,bridge=vmbr1,tag=4
numa: 0
onboot: 1
ostype: win10
sata0: blue:vm-103-disk-2,cache=writeback,discard=on,mbps_rd=100,mbps_rd_max=100,mbps_wr=100,mbps_wr_max=100,size=700G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=226d8413-e188-4a76-85a1-2a4711e1c0d8
sockets: 1
startup: order=2
vcpus: 8
vmgenid: 61a75da3-d287-44c1-b487-f876adab84dc
vmstatestorage: blue


# cat /etc/pve/qemu-server/107.conf
agent: 1,fstrim_cloned_disks=1
balloon: 24000
bios: ovmf
boot: order=sata1
cores: 32
efidisk0: black:vm-107-disk-0,efitype=4m,pre-enrolled-keys=1,size=528K
ide0: none,media=cdrom
machine: pc-q35-5.1
memory: 48000
meta: creation-qemu=7.0.0,ctime=1662064854
name: win-swwts2
net0: virtio=66:23:00:2C:81:D4,bridge=vmbr1,tag=4
numa: 0
onboot: 1
ostype: win10
sata1: black:vm-107-disk-1,cache=writeback,discard=on,mbps_rd=100,mbps_rd_max=100,mbps_wr=100,mbps_wr_max=100,size=100G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=acc7fc90-cf10-4695-9e3c-a0b930fd11b2
sockets: 1
startup: order=3
vcpus: 32
vmgenid: efac9253-7873-4dec-8fed-0ccec62549be
vmstatestorage: black


Die 100 sw-easytec ist die mit englischem Windows. Die hatte nie Probleme. Alle anderen hatten mehrfach Probleme. Wie gesagt jetzt aber alle auf SATA gestellt. Vorher waren die mit SCSI-VirtIO.

black ist ein ZFS SSD Storage mit Mirror (2 Intel SSDs)
blue ist ein ZFS SSD Storage mit RaidZ1 (4 Samsung SSDs)
 
und bitte mal prüfen ob wirklich die ganze VM fritte ist bzw. filesystem korrupt oder ob es das "partitionstabelle weg" problem ist

Dazu müsste ich nochmal eine abrauchen lassen. Ich hatte beide Backupsysteme zuerst VZDump auf ein ZFS Directory (2x10 TB IDE) und später dann auf einen PBS. Ist egal, tritt in beiden Fällen auf.
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!