VirtIO-Installation 0.1.271 auf Windows Server 2019 schlägt fehl/geht nicht

[oelk]

Hallo zusammen,

auf unserem Proxmox-Cluster haben wir 3x Windows-Server 2019 verteilt für einen Failovercluster.
Bei zweien geht die installation der neuen Version 0.1.271 (virtio-win-0.1.271.iso, virtio-win-gt-x64.exe) gut.
Bei einem geht das nicht.
Da kommt dann eine 'Rolling Back Action'.
Unter 'Programme und Features' ist da auch garnix gelistet im Gegensatz zu den beiden anderen.

Wird irgendwo von der Installation ein Log-File geschrieben, in dem ich einen möglichen Fehler lesen kann?

Von der Hardware-Definition und den Optionen in Proxmox sind alle drei gleich definiert, dummerweise der OS-Type auf Linux, da hat man bei der Migration von Linux/KVM nicht richtig hingeschaut, vermute ich.
Und als weiteren Unterschied sehe ich im Gerätemanager auf der Problem-Installation das Laufwerk als 'Red Hat VirtIO DiskDevice', auf den beiden anderen 'QEMU HARDDISK'
Könnte hier das Problem liegen?
Wie ändert man sowas?

Die weiteren Eckdaten:
pveversion:
pve-manager/9.1.5/80cf92a64bef6889 (running kernel: 6.17.4-2-pve)

MfG

 

[Falk R.]

Hallo zusammen,

auf unserem Proxmox-Cluster haben wir 3x Windows-Server 2019 verteilt für einen Failovercluster.
Bei zweien geht die installation der neuen Version 0.1.271 (virtio-win-0.1.271.iso, virtio-win-gt-x64.exe) gut.
Bei einem geht das nicht.
Da kommt dann eine 'Rolling Back Action'.
Unter 'Programme und Features' ist da auch garnix gelistet im Gegensatz zu den beiden anderen.

Wird irgendwo von der Installation ein Log-File geschrieben, in dem ich einen möglichen Fehler lesen kann?

Da sollte etwas im Eventlog auftauchen.

Von der Hardware-Definition und den Optionen in Proxmox sind alle drei gleich definiert, dummerweise der OS-Type auf Linux, da hat man bei der Migration von Linux/KVM nicht richtig hingeschaut, vermute ich.

Das kannst du ja ändern, aber das hat eigentlich nur Auswirkungen auf die Vorschläge für die virtuelle Hardware.

Und als weiteren Unterschied sehe ich im Gerätemanager auf der Problem-Installation das Laufwerk als 'Red Hat VirtIO DiskDevice', auf den beiden anderen 'QEMU HARDDISK'
Könnte hier das Problem liegen?

Dann ist die Disk per Virtio und nicht per SCSI eingebunden.

Wie ändert man sowas?

Disk detach und per scsi wieder einhängen.

Die weiteren Eckdaten:
pveversion:
pve-manager/9.1.5/80cf92a64bef6889 (running kernel: 6.17.4-2-pve)

Patchen solltest du auch mal.

Alles was du beschreibst, erklärt aber nicht den Fehler. Wie bindest du die shared Disks für den Failovercluster ein?

 

[Mathias Zunterer]

Hi Oelk,

auf unserem Proxmox-Cluster haben wir 3x Windows-Server 2019 verteilt für einen Failovercluster.
Bei zweien geht die installation der neuen Version 0.1.271 (virtio-win-0.1.271.iso, virtio-win-gt-x64.exe) gut.
Bei einem geht das nicht.
Da kommt dann eine 'Rolling Back Action'.
[..]
Und als weiteren Unterschied sehe ich im Gerätemanager auf der Problem-Installation das Laufwerk als 'Red Hat VirtIO DiskDevice', auf den beiden anderen 'QEMU HARDDISK'

Könnte hier das Problem liegen?

Als Idee:
Wenn Du bereits im Gerätemanager ein "Red Hat VirtIO DiskDevice" hast (und alles funktioniert), gehe ich davon aus dass dieser Windows Server auch Treiber dafür hat. Könnten diese neuer sein als 0.1.271, und daher die Installation von virtio-win-gt-x64.exe fehlschlägt? (Es muss nicht sein, dass die Treiber über das Gesamtpaket kamen und daher in "Programme und Features" aufgezeigt werden, es kann auch sein dass bei der Installation jemand die "Treiber-CD eingelegt hat" und dem Installer gesagt hat "hier sind die Treiber für den Controller bzw. die Platte".)
Es gibt seit September 2025 bereits virtio-win-0.1.285

Viele Grüße,

Mathias

 

[oelk]

Da sollte etwas im Eventlog auftauchen.

Du meinst die Windows-Ereignisanzeige?

Das kannst du ja ändern, aber das hat eigentlich nur Auswirkungen auf die Vorschläge für die virtuelle Hardware.

Dann ist die Disk per Virtio und nicht per SCSI eingebunden.

Disk detach und per scsi wieder einhängen.

Das geht mit einer Systemplatte?

Patchen solltest du auch mal.

Alles was du beschreibst, erklärt aber nicht den Fehler. Wie bindest du die shared Disks für den Failovercluster ein?

Über eine zweite vitruelle Netzwerkkarte per iSCSI.

@

Mathias Zunterer​

Ich hab die Treiber per Powershell abgefragt, die sind älter.
Mein Frage war eigentlich:
Hinterlässt 'virtio-win-gt-x64.exe' selbst einen eigenen Log-File? In %TEMP% liegt nichts.
Das wäre Hilfreich.

Übrigens: die Problem-VM hat nicht die aktive Clusterolle, solange wir das nicht gelöst haben.

MfG

 

[Torben Andresen]

Es gibt inzwischen die Treiberversion 0.1.302 Die sind zwar noch nicht offiziell freigegeben, aber bei Problemen würde ich damit mal testen ob die helfen:
https://fedorapeople.org/groups/vir...ownloads/archive-virtio/virtio-win-0.1.302-1/

 

[ThoSo]

Es gibt inzwischen die Treiberversion 0.1.302 Die sind zwar noch nicht offiziell freigegeben, aber bei Problemen würde ich damit mal testen ob die helfen:
https://fedorapeople.org/groups/vir...ownloads/archive-virtio/virtio-win-0.1.302-1/

Selbstverständlich sind die 0.1.302 offiziell frei gegeben.
Seitens Proxmox Staff Team ist im Moment noch die Empfehlung bei der 271 zu bleiben.
Siehe auch : https://forum.proxmox.com/threads/virtio-win-releases.164979/

@oelk - ja im Windows Eventlog (Anwenungen / Install).
Gab es beim Roll-Back eine Fehlermeldung?
Fahr die VM runter und stelle das OS korrekt ein, Boote die Maschine und prüfe die Installation erneut - da kannst du auch mal den Temp Ordner beim Benutzer öffnen und nachsehen ob dort Dateien abgelegt werden (log).

Update 16h
Im Benutzer / APPDATA / TEMP werden für die Virtio-win-guest-Tools LOG Dateien abgelegt - diese werden auch nach der Beendigung der Installation nicht gelöscht. Im Eventlog (WIN) finden sich dann mehrere Einträge - auch der MSI Installer.
Da sollte sich doch etwas finden lassen

 

[Falk R.]

Du meinst die Windows-Ereignisanzeige?

Ja, ich nutze in der Regel Englisch in allen Serverbetriebssystemen.

Das geht mit einer Systemplatte?

Ja, aber. Wenn die VM noch nie ein VirtioSCSI Device gesehen hat, bootet die VM nicht. Das kannst du ganz einfach umgehen. Hänge eine Virtio SCSI Disk ein, schaue ob die im Gerätemanager auftaucht, danach kannst du die Disk wieder löschen und die OS Disk umhängen.

 

[Bu66as]

Die .exe ist nur ein Wrapper ums MSI, daher auch die "Rolling Back Action". Nimm die virtio-win-gt-x64.msi direkt vom ISO und starte sie aus einer Admin-CMD mit Logging:

msiexec /i D:\virtio-win-gt-x64.msi /l*vx C:\virtio-install.log

Dann in der Log nach Return value 3 suchen, ein paar Zeilen drüber steht die Action, die fehlschlägt. Meist kommst du damit schneller ans Ziel als über die Ereignisanzeige. Falls du nach msi*.log suchst: bei elevated Installs landen die nicht im User-%TEMP%, sondern in C:\Windows\Temp.

Der Installer modifiziert auch NetKVM und tauscht dabei kurz die NIC. Wenn dein iSCSI für die shared Disks über diese Karte läuft, ist die Verbindung für ein paar Sekunden unterbrochen. Ich hatte sowas mal bei einem Kunden, da ist der Install genau deswegen gescheitert. Versuch, die iSCSI-Sessions vorher zu trennen.