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.
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.
