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

 

[oelk]

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.

- in %APPDATA% - kein temp vorhanden
- in %TEMP% - nein
- %LOCALAPPDATA% - Temp vorhanden, aber ohne msi*.log
- c:\windows\temp - ohne msi*.log
- hier findet man die Ereignisse:
get-eventlog -logname application | where message -like "*virt*"

Der Ansatz mit msiexec geht, wenn der log in ein c:\temp geschrieben wird:

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

Datei direkt ins Hauptverzeichnis zuschreiben, war noch nie eine gute Idee.

Bei einer Testinstalation zuhause stellt sich raus, das SHIFT + F10 nicht mehr funktioniert, wenn man in einem Konsolenfenster
Windows installieren möchte mit lokalem Benutzer.

FF 140.15.0 ESR unter Windows
Überhaupt geht auch kein Shift,ü,ä,ö,...
Was wurde hier wieder kaputt repariert?

Versucht man eine Baustelle zu untersuchen, tut gleich eine andere auf.

MfG

 

[Falk R.]

FF 140.15.0 ESR unter Windows
Überhaupt geht auch kein Shift,ü,ä,ö,...
Was wurde hier wieder kaputt repariert?

Das ist ganz häufig ein Browserproblem. Je nachdem welche Sprache im Browser und welche in der VM benutzt wird, ist das Tastaturlayout kaputt.
Das Shift nicht geht habe ich noch nie erlebt, das muss wohl am FF liegen. Das Sonderzeichen falsch oder gar nicht gehen ist eher üblich.
Mal Chrome/Chromium probiert. Damit gibts deutlich weniger Probleme. Das ist nicht nur bei Proxmox so, sondern generell bei Browserbasierten Remoteconsolen.

 

[Bu66as]

Was steht denn jetzt in der Log drin? Such nach Return value 3, die Action ein paar Zeilen drüber ist das Problem. Ohne die Zeile bleibt alles andere Raten. Und ja, direkt nach C:\ schreiben scheitert bei aktivem UAC/Ordnerschutz gern mal still, C:\temp ist der bessere Ort.

Das mit Shift+F10 und den fehlenden Umlauten ist aber kein Windows-Problem, das ist die noVNC-Konsole. Die Keymap-Behandlung im Browser ist da schon lange wackelig, Sondertasten und Modifier kommen einfach nicht sauber durch. Nimm für sowas SPICE (virt-viewer), damit funktioniert die Tastatur inkl. Shift+F10 zuverlässig. Alternativ mal in den VM-Optionen mit dem Keyboard-Layout spielen, default vs. explizit de macht bei noVNC teils einen Unterschied. Wenn die Kiste online ist, lieber RDP.

 

[oelk]

Was steht denn jetzt in der Log drin? Such nach Return value 3, die Action ein paar Zeilen drüber ist das Problem. Ohne die Zeile bleibt alles andere Raten. Und ja, direkt nach C:\ schreiben scheitert bei aktivem UAC/Ordnerschutz gern mal still, C:\temp ist der bessere Ort.

Das mit Shift+F10 und den fehlenden Umlauten ist aber kein Windows-Problem, das ist die noVNC-Konsole. Die Keymap-Behandlung im Browser ist da schon lange wackelig, Sondertasten und Modifier kommen einfach nicht sauber durch. Nimm für sowas SPICE (virt-viewer), damit funktioniert die Tastatur inkl. Shift+F10 zuverlässig. Alternativ mal in den VM-Optionen mit dem Keyboard-Layout spielen, default vs. explizit de macht bei noVNC teils einen Unterschied. Wenn die Kiste online ist, lieber RDP.

Zuhause hab ich da keine Probleme, das lässt sich installieren, in die Firma kann ich erst am Montag reinschauen.

Aber folgendes hat sich eben gezeigt:
frische Installation W2019
Bei der Installation vioscsi\2k19\amd64 (0.1.271) auswählen, den Treiber akzeptiert er nicht, alos keine Platte, keine Installation
Mit 0.1.266 geht es.
Da scheint grundsätzlich mit der Version was im Argen zu liegen.

zu SHIFT+F10:
definitiv ein Firefox Problem, mit Edge klappt das.
SHIFT, CTRL, und ALT ist im KonsolenFenster nicht möglich.

Wo kann ich in den VM-Optionen was mit Keyboard machen? Bei mir sehe ich da nix, was nach keyboard aussieht.

MfG