Wie downgrade virtio 1.285 auf 1.271?

Die Fehler traten unmittelbar auf, als ich PBS installiert habe. Fleecing war überall deaktiviert und der Cache stand überall auf Write Back.
Auf einigen Systemen war der Fehler "überborden", d.h. > 100 Einträge in der Ereignisanzeige. Disk Error, RAID System wurde zurückgesetzt, korrupte NTFS Laufwerke, darüber hinaus System-Freezes und eine kaputte Datenbank.
Je größer die Datenmenge der Systeme war und je größer die zum PBS übertragene Datenmenge, desto schlimmer.

Es gab Systeme, auf denen trat der Fehler schon zu beginn nur selten (1 - 10 Einträge über die ersten drei Tage mit Häufungen beim initialen Backup), ohne ernsthafte Konsequenzen (kein korruptes NTFS, kein Freeze).
Es gab auch Systeme, da trat der Fehler gar nicht auf. Das waren Systeme mit wenigen Daten, noch geringeren Backup-Diffs und auf denen zufällig bereits die 271 drauf war.

Auf der anderen Seite waren Systeme, auf denen bereits 271 drauf war nicht automatisch immun. Wenn die Datenmenge groß war, trat der Fehler auch hier auf. Ich geh davon aus: weil Fleecing und No Cache wichtig ist.

Die HAL Version hatte vermutlich keinen Einfluss, aber da ich ohnehin große Änderungen gemacht habe, hab ich die mitgezogen.



Die Änderungen sind jetzt seit ca. 2 Wochen aktiv und ich habe stichprobenartig die besonders "großen" Maschinen geprüft und den Fehler nirgends mehr gefunden, trotz ca. 10 Backups je Maschine, die seit dem gelaufen sind.
Einen besonders betroffenen Rechner (der mit der defekten Datenbank) hatte ich ganz aus der Sicherung genommen und erst vor 2 Tagen wieder aktiviert. Da laufen jetzt ca. 1 TB über die Internet-Leitung und das Problem trat bisher trotzdem noch nicht wieder auf.
Vorher hatte ich im gleichen Zeitraum ~ 100 verschiedene Disk und RAID Controller Meldungen – inkl. einer korrupten MSSQL Datenbank.

Die Host Kernel sind alle auf 7.0.6 bis 7.0.12

Edit: Ein Server ist nach wie vor betroffen. Hab den PBS für dieses Gerät jetzt deaktiviert. Hilft alles nichts.
Also nochmal: Bei ~ 20 Geräten nach obiger Änderung ohne jegliche weitere Fehler. Bei einem Gerät Fehler unverändert. Hardware ist identisch zu funktionerender, anderer Hardware. Ich verstehe beim besten Willen nicht, warum er hier weiter rumzickt.
Macht das Konzept für mich ein bisschen kaputt. Egal, ich bastel mir gerade ohnehin mit der KI ein zfssend-to-restic Skript. Dann brauche ich den PBS nicht mehr :-/
ksnip_20260705-161927.png
 
Last edited:
Ich hatte einen PBS eingerichtet und mir damit verdammt viele Probleme eingefangen.
Config war:
- Host Kernel 7.0.6
- CPU-Type = Host
- Backup Fleecing deaktiviert
- HAL 8.0 bis 10.1
- Single VirtIO SCSI, Write Back Cache
- Windows Server 2019, 2022, 2025
- VirtIO SCSI Treiber verschieden: v228, 262, 271, 285

Ich hatte nächtliche Freezes, disk errors im Ereignismanager, Rücksetzungen des Raid Controllers im Ereignismanager bis hin zu einer korrupten SQL Datenbank (Mega Feeling, wenn man durch einmaligen Sicherung auf dem PBS am Vortag die VZDump Sicherung deaktiviert hat! Yay!). Auffällig wenig Probleme gab es mit v271 (einzelne RAID Controller Rücksetzungen, keine Disk Errors, keine Freezes)

Ich habe alle Maschinen umgestellt auf:
- Backup Fleecing aktiviert
- HAL 11
- Single VirtIO SCSI, No Cache
- VirtIO SCSI Treiber v271
- Host Kernel, CPU-Type, Windows Server unverändert

Bei allen war das Problem im Anschluss gänzlich verschwunden.
Ganz Typisch für Designfehler beim PBS.
 
  • Like
Reactions: Johannes S
Kannst du das genauer ausführen?
Es wird empfohlen den PBS mit SSDs auszustatten.
Wenn der PBS langsam ist, oder langsam angebunden, dann bremst das aktiv das schreiben der VMs während des Backups.

Beim Backup werden einfach alle geänderten Blöcke gelesen. Möchte in der Zeit die VM einen der zu sichernden Blöcke neu beschreiben, dann wird der I/O angehalten bis der Block gelesen und auf dem PBS geschrieben wurde.
Das ganze kann man entschärfen wenn man fleecing auf eine SSD macht wo die Blöcke zwischengespeichert werden, bis der Server PBS wieder Daten annimmt.
 
  • Like
Reactions: Johannes S
@ivenae danke für die Infos, @Falk R. danke für den Input zum PBS.

Den PBS hab ich bei uns nicht im Verdacht. Dessen Storage könnte zwar sicher noch schneller sein, aber nachdem die VM-Hickups eher vormittags entstehen, wenn grade keine Backups laufen (sollten ...), dürfte es bei uns was anderes sein.

Bislang fahren die 2 Problem-VMs nun ruhig, dies nur am Rande. Zur Erinnerung: Host-Kernel 6.x, Machine-Type 10 ...

Vielleicht wäre es cool, eine kleine Umfrage zu starten? Und zwar die Leute zu befragen, deren Win-2025-VMs ruhig und stabil laufen: welche virtio-Version, welche Machine-Types, vCPU usw.
 
Mir fiel gestern Abend spontan ein, warum die eine Maschine noch rumzickt und ich bin mir recht sicher, dass ich die Lösung weiß; insbesondere weil die Hardware teilweise identisch ist wie bei Geräten, wo es läuft:

Der betroffene Kunde hat eine sehr langsame Internetverbindung (10 MBit/s Upstream) und gleichzeitig einen 1und1 Anschluss mit einer Zwangstrennung. Ich wollte das initiale Backup daher so zeitlich steuern, dass es nicht durch die Zwangstrennung gestört wird (bisher nutze ich leider noch kein Wireguard, dem wäre die Trennung wohl egal, sondern SSH Tunnel, der dann unweigerlich mit abbricht).

Also hab ich am WE jeweils die Internetverbindung neu verbunden und dann bei den zwei VMs jeweils auf den Backup Knopf der Maschine gedrückt. Einmal Freitag Abend, einmal Samstag Mittag.
Der Backup-Now Knopf der Maschine übernimmt aber die Fleecing Einstellung des Hauptjobs nicht, d.h. das Backup lief ohne Fleecing.
Fleecing ist entsprechend der Ausführung von Falk R. unbedingt notwendig, damit die Fehler nicht auftreten.

Umso mehr stört es mich gerade, dass ich beim Backup-Now Button in den einzelnen VMs keine Fleecing Einstellung übernehmen kann.
Anders ausgedrückt: Der Backup-Now Button bedeutet für mich gerade "Backup Now and immanent destroy databases and NTFS MFT on the system".
Das ist ein Halt-and-catch-Fire Button, den man keinesfalls drücken darf.
 
Last edited:
@ivenae danke für die Infos, @Falk R. danke für den Input zum PBS.

Den PBS hab ich bei uns nicht im Verdacht. Dessen Storage könnte zwar sicher noch schneller sein, aber nachdem die VM-Hickups eher vormittags entstehen, wenn grade keine Backups laufen (sollten ...), dürfte es bei uns was anderes sein.

Bislang fahren die 2 Problem-VMs nun ruhig, dies nur am Rande. Zur Erinnerung: Host-Kernel 6.x, Machine-Type 10 ...

Vielleicht wäre es cool, eine kleine Umfrage zu starten? Und zwar die Leute zu befragen, deren Win-2025-VMs ruhig und stabil laufen: welche virtio-Version, welche Machine-Types, vCPU usw.
Die 2025 sollten immer ohne nested virtualisierung Flag bei der CPU laufen, sonst wird es by Design langsam.
Das soll zwar mit qemu11 gefixt sein/werden aber dazu habe ich noch nicht genug getestet.
 
  • Like
Reactions: Johannes S and sgw
Die 2025 sollten immer ohne nested virtualisierung Flag bei der CPU laufen, sonst wird es by Design langsam.
Das soll zwar mit qemu11 gefixt sein/werden aber dazu habe ich noch nicht genug getestet.
Ich habe von dem Problem gehört, konnte das aber nicht reproduzieren bei mir.
Die CPU Last war niedrig, aber es laufen auch oft nur 1 oder 2 Maschinen drauf, dann fällt es ggf. nicht so auf.

Und ich behaupte, dass ich auf solche Ressourcenverschwendungen ggü. anderen IT-lern eher sensibel reagiere.
 
Last edited:
Die 2025 sollten immer ohne nested virtualisierung Flag bei der CPU laufen, sonst wird es by Design langsam.
Das soll zwar mit qemu11 gefixt sein/werden aber dazu habe ich noch nicht genug getestet.

Gute Info, ich muss mir das auch noch genauer ansehen, denn ich kann und will nicht dauerhaft auf einem Server auf Kernel 6.x und/oder machine-type 10.0 bleiben. Klingt für mich also nach Richtung:

* Host-Kernel 7.0.x
* Machine-Type 10.1
* vCPU: x86-64-v3 mit explizit abgeschaltetem nested-virt

Zumindest als vorläufige best practice. Übersehe ich etwas?

Beim Storage habe ich grade drin:

Virtio SCSI single, cache=writeback, discard=on, iothread=1 .. evtl noch mal relevant, weil wir ja ursprünglich (Thread-Starter-Thema) den virtio-storage-Treiber "downgraded" haben.
 
Gute Info, ich muss mir das auch noch genauer ansehen, denn ich kann und will nicht dauerhaft auf einem Server auf Kernel 6.x und/oder machine-type 10.0 bleiben. Klingt für mich also nach Richtung:

* Host-Kernel 7.0.x
* Machine-Type 10.1
* vCPU: x86-64-v3 mit explizit abgeschaltetem nested-virt
Bei x86-64-v3 ist immer ohne Nested Virtualisierung. Du kannst auch host mit explizit deaktivierten Nested Virtualisierung nehmen. Da kann die VM alle CPU Features nutzen.
Zumindest als vorläufige best practice. Übersehe ich etwas?

Beim Storage habe ich grade drin:

Virtio SCSI single, cache=writeback, discard=on, iothread=1 .. evtl noch mal relevant, weil wir ja ursprünglich (Thread-Starter-Thema) den virtio-storage-Treiber "downgraded" haben.
Ich bleibe auch erst einmal bei der 271. Cache lasse ich bei den VMs aus, da man den unterschied in der Regel eh nicht merkt. Zumindest bei Enterprise Hardware.
 
  • Like
Reactions: Johannes S and sgw