Geänderte Hardware beim Update von qemu 5.1 auf 5.2

Message

l3u · Post by **l3u** » Mon Jan 25, 2021 1:21 pm

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 · Post by **mike155** » Mon Jan 25, 2021 1:37 pm

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:

Code: Select all

/usr/bin/qemu-system-x86_64
    -enable-kvm
    -cpu SandyBridge,+pcid
    -smp 2
    -machine type=q35,accel=kvm
    -vga cirrus
    -drive file="/mypath/win10.img",if=virtio,index=0,media=disk,cache=writeback
    -drive file="/mypath/virtio-win-0.1.171.iso",index=2,media=cdrom
    -rtc base=localtime
    -name 'Windows 10'
    -net nic,model=virtio,macaddr=00:22:22:22:22:22
    -net tap,ifname=tap2,script=no
    -monitor telnet:127.0.0.1:5802,server,nowait,nodelay
    -vnc 127.0.0.1:2
    -device nec-usb-xhci
    -device usb-tablet
    -daemonize
    -k de
    -m 4096

l3u · Post by **l3u** » Mon Jan 25, 2021 2:14 pm

Bei mir sieht das folgendermaßen aus:

Code: Select all

qemu-system-x86_64 \
    -machine accel=kvm \
    -monitor stdio \
    -smp 2 \
    -m 2G \
    -drive file="system.qcow2",if=virtio \
    -device virtio-net-pci,mac="XX:XX:XX:XX:XX:XX",netdev=net0 \
    -netdev id=net0,type=tap,ifname=tap0,script=no,downscript=no \
    -usb \
    -device usb-tablet \
    -rtc base=localtime

Mich hat es gewundert, dass "-machine type=pc-i440fx-5.1" überhaupt keinen Unterschied gemacht hat … wo kommt die geänderte Hardware her?! "pc-i440fx-5.1" war der Standard bei 5.1, für 5.2 ist es entsprechend "pc-i440fx-5.2".

l3u · Post by **l3u** » Mon Jan 25, 2021 6:45 pm

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 · Post by **mike155** » Mon Jan 25, 2021 8:25 pm

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 · Post by **l3u** » Tue Jan 26, 2021 11:13 am

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 · Post by **firefly** » Tue Jan 26, 2021 1:02 pm

l3u wrote: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 …

Mike hat geschrieben, dass es bei Ihm nicht passiert.
Daher würde ich vermuten, dass der unterschied zwischen euch beiden im aufruf von qemu liegt. Gut möglich dass du mit deinem aufruf irgendwelche default params nicht abänderst und diese sich in version 5.2 verändert haben.

Prüf mal welchen machine type qemu bei dir mit 5.1 und mit 5.2 verwendet. Wenn der sich ändert würde ich stark vermuten, dass das gast system quasi komplett neue hardware sieht

firefly · Post by **firefly** » Tue Jan 26, 2021 9:37 pm

l3u wrote: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.

Um welche geräte handelt es sich denn genau, neben der Netzwerkkarte.
Eventuell werden einige der Geräte (vermutlich PCI) auf anderen "Ports" dem Gast dargeboten.

Daher wohl auch die bitte von mike.
Dadurch sieht man genau was sich ändert

l3u · Post by **l3u** » Wed Jan 27, 2021 11:02 am

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 · Post by **mike155** » Wed Jan 27, 2021 2:45 pm

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 · Post by **mike155** » Thu Jan 28, 2021 1:23 pm

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 · Post by **l3u** » Thu Jan 28, 2021 4:36 pm

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

mike155 · Post by **mike155** » Thu Jan 28, 2021 10:50 pm

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

Code: Select all

lscpu, lspci -nn, lspci -v -nn, lsusb, lsusb -v, inxi -v8 -xxx, dmesg, dmidecode

zeigen die gleiche Hardware. Es gibt nur ein paar minimale Abweichungen, die aber zu erwarten sind und vermutlich bei jeder Versionsänderung von QEMU auftreten:

Code: Select all

-   Product Name: Standard PC (Q35 + ICH9, 2009)
-   Version: pc-q35-5.1
+   Product Name: Standard PC (Q35 + ICH9, 2009)
+   Version: pc-q35-5.2

Wirklich merkwürdig... Wieso meint Windows nur, dass sich etwas geändert hat?

Einen winzigen Unterschied sieht man beim SCSI Controller:

Code: Select all

00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device
    Subsystem: Red Hat, Inc. Virtio block device
    Flags: bus master, fast devsel, latency 0, IRQ 20
    I/O ports at c000 [size=128]
    Memory at febd6000 (32-bit, non-prefetchable) [size=4K]
    Memory at fe004000 (64-bit, prefetchable) [size=16K]
-   Capabilities: [98] MSI-X: Enable+ Count=2 Masked-          # <-- QEMU 5.1
+   Capabilities: [98] MSI-X: Enable+ Count=3 Masked-          # <-- QEMU 5.2
    Capabilities: [84] Vendor Specific Information: VirtIO: <unknown>
    Capabilities: [70] Vendor Specific Information: VirtIO: Notify
    Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg
    Capabilities: [50] Vendor Specific Information: VirtIO: ISR
    Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg
    Kernel driver in use: virtio-pci

Ob dieser Unterschied Windows veranlasst, eine neue Netzwerkkarte anzunehmen und neue Treiber zu installieren?

mike155 · Post by **mike155** » Fri Jan 29, 2021 4:57 pm

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 · Post by **l3u** » Sat Feb 06, 2021 9:57 am

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

Mein Reden!!!