Geänderte Hardware beim Update von qemu 5.1 auf 5.2

[l3u]

Hallo allerseits!

Bei dem kürzlichen Update von qemu 5.1 auf 5.2 scheint sich ja einiges an der Hardware geändert zu haben, die das Guest-OS sieht. In meiner Windows-7-VM musste ich z. B. die Netzwerkkarte neu konfigurieren, weil die als Neue aufgetaucht ist, und die Alte war weg.

Jetzt hab ich in der Arbeit (wegen "never change a running system") einen Windows SBS 2003 via qemu laufen. Ich hab mal per Trockenübung ein Backup der VM mit qemu 5.2 gestartet. Ich musste dann allerlei virtio-Treiber neu installieren (glücklicherweise möglich mit dem entsprechenden CD-Image), und auch das Netzwerk neu konfigurieren. Das Windows will sogar wegen "umfassender Hardwareänderungen" neu aktiviert werden.

Die letzten 7 Jahre musste ich nie inenrhalb der VM irgendwas ändern nach einem Update. Ich habe auch nirgends was gefunden, wo stehen würde, dass die Hardware sich geändert hat. Wie kann man das im Vorfeld rausfinden?

Ich habe auch probiert, die Option "-machine type=pc-i440fx-5.1" zu setzen, damit sich nichts am virtuellen Computer ändert, aber das hat keine Auswirkung; die Hardware ändert sich genauso. Kann ich qemu 5.2 sagen, dass es sich der VM gegenüber bitte genauso verhalten soll, wie 5.1?

Vielen Dank für jede Hilfe!

[mike155]

Bei mir lief das Update auf QEMU 5.2 relativ problemlos. Meine Windows 10 VM startet ohne Probleme und ohne Meldungen zu geänderter Hardware. Auch die Linux VM zeigt keine geänderte Hardware an (diff von dmesg von QEMU 5.1 und 5.2).

Wie startest Du QEMU/KVM? Direkt mit /usr/bin/qemu-system-x86_64? Oder über libvirt bzw. eine GUI?

Ich starte meine Windows VM folgendermaßen:

[l3u]

Bei mir sieht das folgendermaßen aus:

[l3u]

Ich hab's grad nochmal per Snapshot getestet: qemu 5.1.0-r2 und 5.1.0-r3 → Windows-VM startet normal, qemu 5.2.0-r1 → Windows will verschiedene Geräte, darunter die Netzwerkkarte neu installieren … unabhängig davon, ob ich eine Angabe zu machine type= mache.

[mike155]

Starte doch mal Linux mit QEMU 5.1 und 5.2 - und schaue, ob es da irgendwelche Unterschiede gibt. Dazu kannst Du Die Ausgabe von lscpu, lspci -nn, lsusb, inxi -F und dmesg vergleichen.

[l3u]

Die Frage ist ja nicht, ob sich die Hardware ändert (ich sehe ja, dass sie es tut), sondern wieso – und ob ich es verhindern kann …

[firefly]

[firefly]

[l3u]

Fängt an mit der Graphikkarte. Die VM startet mit 640x480 px Auflösung.

Dann will/muss Windows folgende Geräte neu installieren:
- QEMU FwCfgDevice (was auch immer das ist)
- Red Hat VirtIO Ethernet Adapter (die alte Netzwerkkarte ist weg)
- Red Hat VirtIO SCSI Controller

… naja, und in der Folge wäre dann auch noch eine Neuaktivierung nötig. Ich hab das bisher nur mit einem Backup ausprobiert, nocht nicht mit dem "richtigen" Live-Server. Ich bin ja froh, dass ich den Kram scheinbar überhaut noch bekomm für DinosaurOS …

[mike155]

Wie gesagt: bei mir hat sich nichts an der simulierten Hardware geändert. Im Changelog steht auch nichts zu Änderungen an der simulierten Hardware. Und die Internet-Foren sind auch nicht voll mit Meldungen von frustrierten Anwendern. Es handelt sich also wahrscheinlich um einen ganz speziellen Fall auf Deiner Maschine.

Die Schlussfolgerung "simulierte Hardware hat sich geändert, weil Windows neue Treiber installieren will" überzeugt mich nicht. Nur weil Windows 7 anfängt wie wild neue Treiber zu installieren, muss sich die simulierte Hardware nicht groß geändert haben. Bei Windows 7 reichen da schon kleinste Änderungen. Wenn ich mich richtig erinnere, hat bei Windows 7 bereits die Änderung der MAC-Adresse dazu geführt, dass eine Neu-Aktivierung notwendig wurde. Windows 10 scheint mir etwas toleranter zu sein.

Es wäre also gut, wenn Du herausfinden könntest, was sich genau geändert hat. Da Windows die Unterschiede nicht anzeigt, könntest Du mit Deinen QEMU 5.1 und 5.2 Startbefehlen Linux starten und Dir die simulierte Hardware ausgeben lassen. Ein Diff zeigt dann die Unterschiede. Und dann wird sich wahrscheinlich auch eine Lösung finden lassen.

[mike155]

Mittlerweile kann ich die Beobachtungen von i3u bestätigen. Irgendetwas ändert sich beim Wechsel auf QEMU 5.2.

Meine Windows 10 VMs sind nach dem Wechsel ohne Fehlermeldung und ohne Probleme gestartet - und zunächst sah alles so aus, als wäre alles in Ordnung und als hätte sich nichts geändert.

In Wirklichkeit hat Windows 10 jedoch im Hintergrund neue Netzwerkadapter installiert. Dabei hat es meine alten, statischen Netzwerkeinstellungen überschrieben und DHCP eingerichtet. Ich habe das erst jetzt gemerkt, weil einige meiner Netzwerkprogramme nicht mehr funktionen.

Ich werde mir das heute Abend ansehen. Sobald ich weiß, was sich bei QEMU 5.2 ändert, werde ich es posten.

[l3u]

Mein Reden … und das erste Mal seit mindestens 7 Jahren.

[mike155]

Ich habe eine Linux VM geclont und parallel unter QEMU 5.1 und 5.2 gestartet. Die üblichen Anweisungen

[mike155]

Ich habe das weiter untersucht. Die Interrupts in den Guest VMs sind unterschiedlich konfiguriert zwischen QEMU 5.1 und 5.2 . Man sieht es im VM-Monitor mit "info pic" und unter Linux, wenn man sich die Interrupt-Konfiguration näher ansieht.

Ich weiß aber nicht, ob die unterschiedliche Interrupt-Konfiguration Zufall ist - oder ob sie für die Neu-Konfiguration der Hardware unter Windows verantwortlich ist. Ich weiß auch nicht, ob es ein generelles QEMU-Problem ist - oder ob das Problem nur unter Gentoo auftritt. Hier gab es einige Änderungen am ebuild zwischen 5.1 und 5.2.

Ich finde das Ganze sehr mysteriös - insbesondere weil man weder mit Google, noch in der QEMU Bug Database etwas zu diesem Problem findet.

Das Verhalten von Windows 7 "laut schreien und Treiber neu installieren" kann ich noch einigermaßen nachvollziehen. Das Verhalten von Windows 10 "Treiber im Hintergrund neu installieren und dabei von statischer Konfiguration auf DHCP wechseln und IPv6 einschalten" ist hingegen gefährlich. Das merkt man erst, wenn die Programme nicht mehr funktionieren.

[l3u]