[SOLVED] Windows Server 2022 virtio

[Falk R.]

Die neueste Virtio 217-2 kann da keine große Änderung bringen. Vermutlich ist das Problem beim installieren, wenn die Geräte zum ersten Mal erkannt werden und dann in der Registry verewigt werden. Früher hatte oft die deutsche Benennung von einigen Komponenten, Stress gemacht. Z.B. Netzwerk statt Ethernet. Das ist auch der Grund warum ich immer wenn es geht Englische ISO benutze.
Physikalisch lassen sich einige RAID Controller nicht administrieren weil das Programm die Gruppe Administrators erwartet und Administratoren nicht kennt. Die Probleme mit deutschen ISO sind also vielfältig und nicht immer leicht durch dritte zu beheben.

 

[Toranaga]

Das hatte ich schonmal im Rahmen von Ansible-Rollout-Tests mit 2019 ausprobiert.

Wenn man mit 6.0 die .215 installiert, dann auf 6.2 umschaltet und auf .217 updaten will, kommt die Rollbackmeldung.
Somit wird vermutlich bei: Q35 6.0 und Win 2019 und Virtio .217 nach dem Umschalten auf 6.2 ein Update der virtio später nicht möglich sein.

Spätestens wenn ein ernsthaftes Problem mit den erstinstallierten Treibern auftauchen sollte, wird das dann zum Problem. Die Maschinenversion darf also bis auf weiteres dann nicht erhöht werden.

P.S.
Korrektur, gerade nochmal mit aktuellsten Treibern getestet. Das macht obiges dann hinfällig.
Mit den .217-2 Treibern klappt das Update von .215 auch wenn die Maschine inzwischen auf 6.2 ist.

 

[wida]

interessant das funktioniert tatsächlich.

Windows Server 2022 mit Q35 V6.0 installieren. Virtio Treiber Version .215-2 die Netzwerkkarte und SCSI Controller installieren.
Kiste runterfahren und auf Q35 V6.2 umstellen.
Kiste hochfahren und Netzwerkkarte und SCSI Controller mit Virtio Treiber Version .217-2 aktualisieren.
Jetzt die restlichen benötigten Virtio Treiber Version .217-2 installieren. (z.B. Balloon)
Danach noch den Balloonservice und den QEMU-Agent installieren.
Fertig ist eine saubere VM mit Q35 V6.2 und den aktuellsten Virtio Treibern.

Wie stabil und sauber allerdings diese dann wirklich ist, wird erst ein nächstes Windowsupdate oder Update der Virtio Treiber zeigen.

Edit:
Workaround mit Vorsicht zu genießen. Wenn man dann in der VM mit Q35 V6.2 eine neue oder zusätzliche Netzwerkkarte installiert hängt man wieder beim selben Problem.
Also bleibt eigentlich erstmal nur Windows Server 2022 mit Q35 V6.0 installieren und so lassen. Virtio Treiber Version .215 oder höher nutzen.

 

[mscd]

Hallo zusammen ... gibt es zu dem Thema schon Neuerungen.

Hab gerade das Problem, dass ich nach einem Upgrade von 2016 auf Windows Server 2022 im Nachgang noch die virtio-Treiber aktualisieren wollte ... mit dem Effekt, dass jetzt die NIC nicht mehr geht. Diverses deinstallieren unterschiedlicher Treiber-Versionen (in Kombination mit q35-6.2 bis -6.2) brachten ebenfalls keinen Erfolg.

Muss ich jetzt ernsthaft den Windows Server neu aufsetzen, da die Treiber-Integration nur bei der Installation aktuell klappt?

 

[wida]

Ich habe es gerade mal mit den neusten ISOs Treibern usw. probiert. Leider kein Erfolg.

Die Kombination funktioniert nicht:
Maschinentyp: pc-q35--6.2
SW_DVD9_Win_Server_STD_CORE_2022_2108.11_64Bit_German_DC_STD_MLF_X23-17136.ISO
virtio-win-0.1.221.iso

Die Netzwerktreiber funktionieren weiterhin nur mit:
Maschinentyp: pc-q35--6.0

 

[CarstenMartens]

Ich habe es gerade mal mit den neusten ISOs Treibern usw. probiert. Leider kein Erfolg.

Die Kombination funktioniert nicht:
Maschinentyp: pc-q35--6.2
SW_DVD9_Win_Server_STD_CORE_2022_2108.11_64Bit_German_DC_STD_MLF_X23-17136.ISO
virtio-win-0.1.221.iso

Die Netzwerktreiber funktionieren weiterhin nur mit:
Maschinentyp: pc-q35--6.0

Hab es eben mit der gleichen ISO und VirtIO und Maschinentyp pc-q35--7.0 versucht. Geht auch nicht.
Die Installation des netzwerktreibers funktioniert bei mir weiterhin nur mit pc-q35--6.0 und Virt IO 0.215-2

 

[ITT]

Hab es eben mit der gleichen ISO und VirtIO und Maschinentyp pc-q35--7.0 versucht. Geht auch nicht.
Die Installation des netzwerktreibers funktioniert bei mir weiterhin nur mit pc-q35--6.0 und Virt IO 0.215-2

Genau wie bei mir.
Abgesehen von der "Extra-Klickerei" funktioniert es doch eh akzeptabel...
Hatte vor einer Woche eine Clustermigration mit 30+ VMs, man gewöhnt sich daran

 

[cwt]

Noch ein Nachtrag zur Variante "Installation mit EN Version & Umstellung auf DE mittels LP":

Sobald das Language Pack (LP) für DE installiert wurde, DE als Standard-Systemsprache eingestellt ist und die Q35 >6.0 ist, kann keine weitere NIC ohne die bekannten Fehler installiert werden. Dann tauchen die altbekannten Probleme wieder auf. Solange man mit der EN-Version unterwegs ist, klappt alles ohne Probleme - auch mit den aktuellen VirtIO Treiber 0.1.221 .

Stellt man die Sprache wieder zurück auf EN und startet die VM neu, wird die NIC sofort sauber installiert.

 

[RolandK]

@cwt , was genau hast du wo eingestellt für die sprachsettings bzw. welche genaue windows iso verwendest du?

ich versuche das was du schreibst gerade mit einer 22H2 zu reproduzieren (mit i440fx-6.1 oder q35-6.1) - leider gelingt mir das partout nicht.

ich wollte deinen fund unter

https://gitlab.com/qemu-project/qemu/-/issues/774
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/750

berichten und ihn aber vorher nochmal verifizieren

 

[cwt]

@cwt , was genau hast du wo eingestellt für die sprachsettings bzw. welche genaue windows iso verwendest du?

ich versuche das was du schreibst gerade mit einer 22H2 zu reproduzieren (mit i440fx-6.1 oder q35-6.1) - leider gelingt mir das partout nicht.

ich wollte deinen fund unter

https://gitlab.com/qemu-project/qemu/-/issues/774
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/750

berichten und ihn aber vorher nochmal verifizieren

Ich habe die offiziellen ISOs von MS verwendet (EN Version). Setup der VMs jeweils als Q35 V7.0 und mit TPM. Die NICs als Virtio Variante. Installationstoutine normal durchlaufen lassen, Virtio Treiber .221 installiert, dann nach dem ersten Reboot für aktuelle Updates das Sprachpaket für DE hinzugefügt, Region und Standardsprache entsprechend umgestellt, erneuter Reboot und Anmeldung über die „DE-GUI“ bzw. RDP.

Fährt man die VM nun herunter und fügt eine weitere NIC hinzu, tritt der Fehler nach der Anmeldung im Gerätemanager wie bekannt auf. Setzt man die Sprache zurück auf EN als Standard und rebootet die VM, wird die NIC ohne Probleme erkannt.

 

[RolandK]

danke. kannst du mir noch sagen welche ISOs bzw. welche windows Version? (z.B. 21H1...)

 

[cwt]

danke. kannst du mir noch sagen welche ISOs bzw. welche windows Version? (z.B. 21H1...)

Das waren jeweils die offiziellen EN-ISOs von MS für 21H2 LTSC. Die SHA1 habe ich jetzt momentan nicht zur Hand.

 

[cwt]

Noch ein weiterer Nachtrag:

Zu Testzwecken habe ich sowohl Server 2019 als auch Server 2022 als DE-Version installiert. Danach habe ich in beiden VMs via gemountete Language-Pack ISO EN-US als Sprache hinzugefügt, diese via PowerShell als Standard gesetzt und die VM danach rebootet.

Im Gegensatz zur "echten" EN-ISO tritt der Fehler hier immer noch auf. Obwohl die Standardsprache nun EN-US ist (EN-GB macht auch keinen Unterschied), scheitert die Installation mit einem Timeout:

The driver for this device are not installed. (Code 28)

This operation returned because the timeout period expired.

Es bleibt also nach wie vor nur der Weg über die "original" Englische ISO, dem Einrichten der NICs/Treiber und dem Hinzufügen von DE als LP. Sollte danach eine weitere virtuelle NIC hinzugefügt werden, muss die Standardsprache wieder auf EN zurück, reboot und dann klappt es wiederum mit der Treiberinstallation (siehe mein Posting weiter oben).

Was auch immer da MS mit den DE-Versionen verbrochen hat... Besserung scheint ja nicht in Sicht zu sein.

 

[RolandK]

>Was auch immer da MS mit den DE-Versionen verbrochen hat... Besserung scheint ja nicht in Sicht zu sein.

könnten evtl mal noch mehr leute das problem an microsoft melden? z.b. über den feedback hub wenn es keine anderen , bessern wege gibt?

 

[RolandK]

@dcsapak , kann proxmox da nix machen und würde es nicht mehr bringen, wenn ein hersteller auf einen anderen hersteller zugeht?

ich würde sonst meine energie mal dransetzen um mehr aufmerksamkeit für dieses thema zu schaffen. es sind wirklich viele von diesem problem betroffen, auch ausserhalb der proxmox community. es kann auch nicht im interesse von microsoft sein, daß leute es mit ihrem OS auf kvm so schwer haben...

 

[dcsapak]

@dcsapak , kann proxmox da nix machen und würde es nicht mehr bringen, wenn ein hersteller auf einen anderen hersteller zugeht?

ich würde sonst meine energie mal dransetzen um mehr aufmerksamkeit für dieses thema zu schaffen. es sind wirklich viele von diesem problem betroffen, auch ausserhalb der proxmox community. es kann auch nicht im interesse von microsoft sein, daß leute es mit ihrem OS auf kvm so schwer haben...

soweit ich weiß sind wir nicht zahlender kunde von Microsoft und haben auch sonst keine Geschäftsbeziehung zu ihnen, d.h. auch keinen Ansprechpartner
meiner Erfahrung nach kommt man nicht so leicht an Leute ran die hier mehr Aufschluss geben könnten ohne jemanden zu kennen bzw. großer Kunde/Partner zu sein

Ich weiß auch nicht ob wir hier soviel Windows know-how haben um es überhaupt vernünftig zu debuggen.

als das problem damals zum ersten mal auftrat, habe ich (und ich glaube einige Kollegen) einige zeit reingesteckt um herauszufinden welche Änderung in qemu dazu geführt hat, allerdings ohne Ergebnis
(ich habe versucht Optionen/Änderungen durchprobiert die der neue machine-type hat wieder zurückzusetzen, kein option hat allerdings einen unterschied gemacht)

ich verstehe dass das problem frustrierend ist, aber ich glaube das problem könnte schneller gelöst werden wenn die qemu maintainer mit microsoft zusammenarbeiten würden
(wir sind ja großteils auch "nur" downstream konsumenten von qemu. wir haben zwar qemu know-how, aber das ist verständlicherweise nicht so groß wie das der maintainer selbst)

also mehr bei microsoft/qemu melden (wo das problem ja ursprünglich herkommt) ist glaube ich der richtige (und hoffentlich schnellste) weg

 

[RolandK]

danke für die info

>als das problem damals zum ersten mal auftrat, habe ich (und ich glaube einige Kollegen) einige zeit reingesteckt um
>herauszufinden welche Änderung in qemu dazu geführt hat, allerdings ohne Ergebnis

da habe ich auch schon einige zeit investiert - leider auch erfolglos.

ok, dann müssen wir wohl den "community druck" erhöhen....

 

[RolandK]

gibt es hier noch jemanden der bitte über ein installiertes win10 ein bugticket über die eingebaute "feedback hub" funktion aufmachen kann ?

vielleicht wachen die ja mal irgenwann auf wenn es 10 tickets dazu gibt, auf mein ticket ist noch keine reaktion erfolgt...

 

[Dunuin]

Kann da vielleicht wer einen Text in Englisch aufsetzen, der das bekannte Problem kurz und knackig zusammenfasst mit den Links zu den Bugreports von PVE, QEMU und Virtio und dann einen neuen Thread dazu starten und es dort posten? Dann könnten wir da Microsoft über Copy&Paste von unserer Win10/Win11/WinServer mit Bug-Reports zuspammen und mal gucken, ob dann wer reagiert.

 

[RolandK]

ich glaube, daß das problem nur bedingt mit der qemu/virtual-hardware version zu tun hat.

ich kann das verhalten auch/selbst in einer frisch installierten deutsch-iso win10 vm mit hardware version 4.0 nachstellen

- vm frisch aufgesetzt ohne nic
- runtergefahren, nochmal gebootet, wieder runtergefahren
- virtual nic e1000 hinzugefügt
- vm hochgefahren - bumms , gelbes dreieck und error code 56.
- virtual nic lässt sich nicht löschen
- nach erneutem boot kann man sie löschen und nach "nach neuer hardware suchen" wird sie gefunden und sauber initialisiert und läuft

bei der englischen passiert es nicht, da funktioniert die nic einfach/immer

in der c:\windows\INF\setupapi.dev.log sieht man daß es für die treiber post-install prozedur nach ca. 4 min einen timeout gibt.

nach dem timeout lässt sich das device im gerätemanager auch wieder löschen. ansonsten sehe ich auf den ersten blick keine unterschiede im log.

die frage ist, was genau passiert beim post-install und warum tritt da dieser timeout auf