Wie downgrade virtio 1.285 auf 1.271?

C

cklahn

Member
Jan 3, 2024
60
3
13
Hallo Forum,

aufgrund der schon beschriebenen Performance-Probleme, möchte ich bei mehreren 2025-Servern die Treiber downgraden. Wie funktioniert das bei schon installierten 1.285-Treibern?

Einfach das ISO einbinden und den Wizard nochmal durchlaufen lassen? Überschreibt der dann die neueren Treiber?
 
Ich gehe bislang immer den Weg deinstallieren und frisch aufspielen.
 
Deinstallation der Treiber oder der ganzen Systems? System geht ja nicht, da die Server bereits im produktioven Umfeld laufen.
 
cklahn said:
Deinstallation der Treiber oder der ganzen Systems? System geht ja nicht, da die Server bereits im produktioven Umfeld laufen.
Click to expand...
Natürlich nur des Guest-Agents :-)
 
Normalerweise müsstest Du über den Gerätemanager gehen, das entsprechende Gerät auswählen, es entfernen und den Treiber dabei löschen.
Den PC / VM neu starten und den älteren Treiber dann über den Gerätemanager installieren.
Evtl. Reicht es auch, den Gerätemanager nach neuer Hardware suchen zu lassen.

Es gibt auch Treiber (prewhql), die mit Experimental im Upstream Ordner bei Fedora gekennzeichnet sind.
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/upstream-virtio/
Die ZIP 0.1.296 enthält Treiber mit Dateidatum vom 02.02.2026 - die würde ich aber vielleicht eher mal auf einem Testsystem probieren, als auf einem Produktivsystem.

Vielleicht lohnt es sich auch zu warten, bis neuere Treiber offiziell veröffentlicht werden.
 
  • Like
Reactions: Johannes S
du solltest normalerweise auch im gerätemanager manuell den älteren treiber zuweisen können:

1771236486897.png

hier sieht man die unterschiedlichen installierten teriberversionen.
ich meine er würde dann auch bei der version bleiben und nicht wieder automatisch updaten.
 
Gibt es da nun Erfahrungen? Ich stehe auch vor der Aufgabe, und sollte das mit möglichst wenig Downtime schaffen.

Reicht es evtl. gezielt den SCSI-Treiber downzugraden, um die bekannten Issues loszuwerden?
 
Ja, im Grunde reicht es den vioscsi-Treiber gezielt runterzusetzen, das ist der, der die Performance-Probleme macht. Der einfachste Weg ist über den Gerätemanager wie @beisser gezeigt hat: Red Hat VirtIO SCSI controller → Eigenschaften → Treiber → "Treiber aktualisieren" → "Auf dem Computer nach Treibern suchen" → "Aus einer Liste verfügbarer Treiber auswählen", dann die ältere Version nehmen. Da brauchst du nix zu deinstallieren und keinen großen Neustart.

Wenn die ältere Version dort nicht auftaucht (weil nur die 1.285er drauf ist), vorher das 1.271er ISO mounten und per "Datenträger" den Pfad zum vioscsi-Ordner angeben. Wichtig: den passenden Unterordner wählen, also vioscsi\2k25\amd64 (oder wie auch immer euer OS-Mapping ist).

@cwt hat nen guten Punkt mit dem winget-Pin, das würd ich direkt mitmachen, sonst holt euch der nächste winget upgrade --all die 1.285er wieder zurück.

Was die Downtime angeht @sgw: der Treiberwechsel über den Gerätemanager braucht einen Reboot, aber das wars. Würd ich trotzdem erstmal an einer VM testen bevor ihr das auf allen Produktiv-Kisten macht.
 
Danke @Bu66as ... ich bin schon durch seit ~30 Minuten ;-) / aber Dein detailliertes Howto ist hilfreich auch für zukünftige Suchende.

Es ging um 2 problematische VMs, die hab ich beide entsprechend "runter-gestuft", inkl. Reboots und Kontrolle der Version danach. winget spielt bei dem Kunden keine Rolle, denke ich. Behalte ich im Hinterkopf.

Sofern sich die 2 VMs nun OK verhalten, sehe ich mir in einem ruhigeren Zeitfenster evtl noch die anderen Treiber an. Netzwerk und SCSI sind nun auf .271, das hab ich jedenfalls geprüft in der Eile.

Die 2 VMs waren relativ random in Hochlast gegangen und mussten danach neu gestartet werden, teils nur per Reset möglich. Lästig.
 
Last edited:
  • Like
Reactions: Bu66as
Leider war's das nicht: beide VMs heute wieder mit Problemen, höre ich gerade vom Kunden.
Sein Admin, der die VMs gebaut hat, ist noch in Urlaub, ich kann ihm zwar vielleicht VMs neu installieren, aber nicht seine Software darin deployen.

Ich kann ihm weiters nur anbieten, die PVEs zu aktualisieren, da sind wir 1-2 Wochen mit Patches im Rückstand (eben aus dem Gedanken heraus, in Abwesenheit des Mitarbeiters nix zu tun, wenn es nicht sein muss).

Ansonsten fehlt mir da grad die Idee.
 
Der Admin hat die Platten der VMs so eingestellt: `cache=writeback, discard=on, iothread=1`

Fragwürdig, oder OK? Sieht für mich eher OK aus.

https://pve.proxmox.com/wiki/Windows_2025_guest_best_practices#Prepare schlägt es auch so vor, meint aber "None" wäre safer, klar.

Nachdem mir sonst noch nicht viel einfällt, würde ich das evtl mal ohne Caching versuchen.

Ausständige Patches der PVEs umfassten "nur" neuere Kernel, keine QEMU-related Packages.
 
Wofür werden die Server denn verwendet? AD-Controller (dann ist caching eigentlich unnötig)? Fileserver? Terminalserver?

Wo genau liegen denn die Performanceprobleme? Wir betreiben bei mehreren Kunden Server 2025 auf PVE mit unterschiedlichen Rollen. Die besagten Probleme aus anderen Threads können wir dort nicht nachvollziehen mit den 285er Treibern.

Was - je nach Hypervisorunterbau - einen Unterschied machen kann, ist das Storage-Setup sowie die Wahl der CPU (host, x86-vX, etc.).
 
Das Bild ist nur der Screenshot aus Post #7 (Treiber-Auswahl im Gerätemanager), keine neue Info. Der letzte Post (#13) von sgw stellt eine konkrete offene Frage zum Cache-Mode, also passt ein voller Entwurf, der die neuen Posts (#12/#13) adressiert.

Hier der Entwurf:

---

Hm, wenn der vioscsi-Downgrade nichts gebracht hat, würd ich nicht mehr davon ausgehen, dass es nur am Treiber liegt. Das Muster (random in Hochlast, danach nur per Reset wieder erreichbar) klingt für mich nach nem QEMU-Problem, nicht nach nem Treiber-Fehler.

Zum Cache: writeback ist nicht der Übeltäter, aber probier ruhig mal cache=none, kostet ja nur einen Reboot. discard=on und iothread=1 sind OK, würd ich so lassen. Für iothread brauchst du virtio-scsi-single als Controller, läuft das? Und steht aio auf io_uring?

Wie sieht's beim Host aus wenn die VM hochgeht, IO-Spike im Graphen oder eher CPU-Last? Und welcher Maschinentyp (pc-q35-x.y) ist gepinnt? Bei mir kamen solche random Freezes nach PVE-Updates schon von nem geänderten q35-Default, da hilft die alte Version pinnen. Ballooning würd ich zum Testen auch mal rausnehmen.

Nicht drei Sachen gleichzeitig ändern, sonst weißt du am Ende nicht was geholfen hat. Erst Cache auf none, beobachten, dann weiter.
 
Die VMs betreiben eine Software, die mein Kunde, ein kleines Software-Haus erstellt, als Backend läuft jeweils ein PostgreSQL-Server.
Normalerweise keine hohe Last, deren Kunden greifen mit RDP auf diese Software zu. (Design-Diskussion aktuell nicht zu führen ...)

Ich habe mal den Virtio-Driver-Installer in v285 komplett deinstalliert und durch v271 ersetzt, um damit hoffentlich sauber auf diese Version zurück zu gehen. Weiters auf PVE-Ebene die CPU von `host` auf `x86-64-v3` gestellt und das Flag für nested-virt abgedreht (habe ich wo aufgeschnappt, URL kann ich nachreichen: EDIT: https://forum.proxmox.com/threads/w...ssd-storage-other-vms-fine.181132/post-840449 ). IO-Caching noch unangetastet.

Das Verhalten wird mir so beschrieben, dass die User plötzlich nix mehr tun können. Im PVE sehen wir steigende CPU-Last.
Eigentlich hab ich Prometheus und windows-exporter am Start, aber da muss ich grade noch was an den Dashboards fixen (wie so oft zieht so eine Recherche Kreise ...).

Zwei, drei Details liefere ich noch nach, bin grad nicht im VPN dort und kann noch nicht nachsehen (iothread, aio).

Ab 14h arbeiten die User wieder mit der einen VM (habe mittags nur eine anpassen können).
 
Last edited:
Das ist nur der Gerätemanager-Screenshot aus #7 (Treiberauswahl SCSI controller), nix Neues. Die neuen Posts #16/#17 beantworten meine Fragen aus #15, dazu mein Entwurf:

---

Gut, die Werte passen alle (io_uring, virtio-scsi-single, pc-q35-10.1), an der Stelle ist nichts auffällig.

Was mich stutzig macht: du hast jetzt Treiber, CPU-Typ und nested-virt auf einmal umgestellt, aber das Caching ist als einziges noch unangetastet, dabei war genau das mein Hauptverdacht. Würd als nächstes wirklich nur cache=none setzen und sonst nix anfassen, sonst weißt du nachher nicht was es war.

Zu host → x86-64-v3: für die Stabilität bringt dir das eher nichts, kostet nur Performance. Wenn du keinen konkreten Migrations-/Mischcluster-Grund hast, würd ich da wieder auf host.

Und wenn die CPU hochläuft und dann einfriert: schau mal genau hin, ob die Last wirklich im Gast liegt (PostgreSQL? eine bestimmte RDP-Session?) oder ob der kvm-Prozess auf dem Host dreht und das IO-Delay mitsteigt. Sobald dein windows-exporter wieder Daten liefert, siehst du ob's CPU oder IO-wait im Gast ist, das grenzt es enorm ein.
 
Danke für die Einschätzung @Bu66as

Die Phänomene treten eher unvorhersehbar auf, ich bin noch am Ausknobeln, wie ich das monitore. Ich nutze Grafana nur punktuell, und stelle fest, dass manche der Windows-Exporter-related dashboards nicht mehr ideal klappen. Prometheus erfasst die Exports von der einen Test-VM jedenfalls.
Ich hab auch Metrics von den PVEs, muss aber erst die richtigen Queries bauen, bzw. Dashboards auswählen.

EDIT: Ich lasse den Kunden nun mal die eine VM beobachten, bzw. die User damit arbeiten. Fallweise als nächstes dann noch besagte Caching-Änderung.
 
Last edited:
  • Like
Reactions: Bu66as
off topic, aber es hängt eben alles mit Allem zusammen :):

Fußnote zu windows_exporter: Der Collector "cs" wurde aus neueren Releases entfernt, soweit ich verstehe, daher zeigen etliche Dashboards manche Instanzen nicht mehr an, weil die zugrundeliegende instance-Query nicht mehr klappt. Da bin ich noch am Suchen, wie ich das anpassen kann (und wundere mich, dass ich das rausfinden muss und es keine angepassten Windows-Exporter-Dashboards dazu gibt ... / wie gesagt: hier off-topic, ich lasse es nur mal hier fallen, weil wer weiß, wer was weiß ... ;) )
 
You must log in or register to reply here.
Top Bottom
Back