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