qemu-Windows-10-Image auf Windows 11 updaten

[l3u]

Hallo allerseits!

Ich habe ein qemu-Windows-7-Image, was ich dazu benutze, ein Cross-Platform-Qt-Projekt auf Windows zu bauen. Spaßhalber habe ich das mal auf Windows 10 upgedatet (nicht, dass ich es bisher benutzt hätte). Und jetzt habe ich spaßhalber mal versucht, das Image auf Windows 11 upzudaten. Das ist ja tatsächlich nicht mehr ganz so einfach.

Von MBR auf UEFI und GPT zu konvertieren hab ich hinbekommen. RAM, CPUs und Festplatte: Alles kein Problem. TPM emulieren und Secure Boot: Auch kein Problem.

Aber: Die Graphikkarte macht Probleme. Ich habe jetzt virtio und qxl als vga auspobiert, aber egal wie: Ich bekomme von WhyNotWin11 als einziges Problem "Direct X 12, aber kein WDDM2", und Windows Update lehnt das Update auf Windows 11 ab.

Hat das einer von euch hinbekommen? Wo hängt's?!

Vielen Dank für alle Hinweise!

[mike155]

Hallo i3u,

da bist Du schon weiter als ich!

Wie konfigurierst Du KVM/QEMU? Über CLI-Parameter? Oder verwendest Du libvirt?

Ich habe bei Google nach "qemu windows 11 guest" gesucht - und etliche Anleitungen gefunden. Hast Du dort mal geschaut? Ist da etwas dabei? Oder entsteht das Problem (nur) dadurch, dass Du ein Upgrade - und keine Neuinstallation - durchführen willst?

Mike

[l3u]

Mit einer Neuinstallation hab ich's bisher gar nicht versucht …

Ich starte qemu mit folgendem Befehl:

Code: Select all

qemu-system-x86_64 \
    -machine q35,smm=on,accel=kvm \
    -cpu host \
    -monitor stdio \
    -smp 2 \
    -m 4G \
    -vga virtio \
    -rtc base=localtime \
    -chardev socket,id=chrtpm,path=$(pwd)/tpm/swtpm-sock \
    -tpmdev emulator,id=tpm0,chardev=chrtpm \
    -device tpm-tis,tpmdev=tpm0 \
    -global driver=cfi.pflash01,property=secure,value=on \
    -global ICH9-LPC.disable_s3=1 \
    -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.secboot.fd,readonly=on \
    -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \
    -drive file="system.qcow2",if=virtio \
    -device virtio-net-pci,mac="00:11:22:33:44:55",netdev=net0 \
    -netdev id=net0,type=tap,ifname=tap0,script=no,downscript=no \
    -device qemu-xhci \
    -device usb-tablet

Die OVMF_*-Dateien hab ich von sys-firmware/edk2-ovmf kopiert (war schon installiert).

Vorher habe ich die virtuelle Maschine von MBR nach GPT/UEFI konvertiert, dazu eine Administrator-Power-Shell aufmachen und dann:

Code: Select all

mbr2gpt /allowfullOS /validate
mbr2gpt /allowfullOS /convert

wobei der erste Befehl keine Fehler ausgespuckt hat. Die Festplatte war schon 100 GB groß.

Ach ja, und vorher muss man noch swtpm starten, das mache ich folgendermaßen:

Code: Select all

#!/bin/bash
swtpm socket --tpm2 --tpmstate dir=$(pwd)/tpm \
    --ctrl type=unixio,path=$(pwd)/tpm/swtpm-sock \
    --log level=20

Sollte man dann später sinnvollerweise in das Start-Script integrieren. Das --log level=20 war jetzt in irgend einer Anleitung gestanden, geht sicher aber auch mit weniger Lärm.

[l3u]

Komisch. Nach ewigem Hin- und Herprobieren steht jetzt auf einmal beim Windows Update dort, dass der PC bereit für das Update wäre. Was man jetzt aber momentan noch nicht machen könnte, sondern erst demnächst. Sehr suspekt. Naja, warten wir's ab?!

Naja, egal wie. Das Start-Script (mit dem es offensichtlich jetzt geht) sieht so aus:

Code: Select all

#!/bin/bash

swtpm socket -d -t --tpm2 --tpmstate dir=$(pwd)/tpm --ctrl type=unixio,path=$(pwd)/tpm/swtpm-sock

qemu-system-x86_64 \
    -machine q35,smm=on,accel=kvm \
    -cpu host \
    -monitor stdio \
    -smp 2 \
    -m 4G \
    -vga virtio \
    -rtc base=localtime \
    -chardev socket,id=chrtpm,path=$(pwd)/tpm/swtpm-sock \
    -tpmdev emulator,id=tpm0,chardev=chrtpm \
    -device tpm-tis,tpmdev=tpm0 \
    -global driver=cfi.pflash01,property=secure,value=on \
    -global ICH9-LPC.disable_s3=1 \
    -drive if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd,readonly=on \
    -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \
    -drive file="system.qcow2",if=virtio \
    -device virtio-net-pci,mac="00:11:22:33:44:55",netdev=net0 \
    -netdev id=net0,type=tap,ifname=tap0,script=no,downscript=no \
    -device qemu-xhci \
    -device usb-tablet \
    $@

echo

[mike155]

Angeregt durch diesen Thread von @i3u habe ich heute die Neu-Installation von Windows 11 in einer QEMU/KVM VM getestet.

Zuerst habe ich folgende Software heruntergeladen:

1. Ein startbares Windows 11 Installationsmedium als ISO Image: Link.
   
   Das Installationsmedium enthält mehrere verschiedene Windows 11 Versionen (Home, Pro, Pro N, usw.). Es kann sowohl für eine Neu-Installation, als auch für ein Update verwendet werden. Wie auch schon bei älteren Windows-Versionen, kann man ohne Lizenzschlüssel installieren und den Lizenzschlüssel später eintragen.
2. Die aktuellen QEMU/KVM VirtIO Treiber für Windows von Fedora als ISO-Image: Link bzw. Link.

Diese beiden ISO-Images habe ich bei allen Tests als CDROM-Laufwerke an das Gast-Betriebssystem durchgereicht.

Code: Select all

-drive file="Win11_German_x64v1.iso",index=2,media=cdrom \
-drive file="virtio-win-0.1.215.iso",index=3,media=cdrom \

Zuerst habe ich die bestehende QEMU-Konfiguration meiner Windows 10 VMs verwendet. Das Installationsmedium startete. Aber ich bekam recht schnell die Meldung, dass die Installation abgebrochen werden müsse, weil die Mindestsystemanforderungen nicht erreicht werden.

Im nächsten Versuch habe ich die von @i3u oben gezeigten Parameter für TPM und Secure Boot zu meiner QEMU-Konfiguration hinzugefügt.

Damit konnte ich Windows 11 installieren - und es läuft auch!

Erstaunlich ist, dass ich Windows 11 trotz meiner 10 Jahre alten Sandybridge XEON CPU installieren konnte. Ich hätte gedacht, dass Windows 11 das nicht zulassen würde.

@i3u:

1. Windows 11 scheint in einer QEMU VM gut zu laufen. Ich kann nicht sagen, ob das Problem bei Dir durch Deine VGA Grafikkarten-Wahl kommt oder ob es ein andere Ursache hat.
2. Hast Du die RedHat VirtIO Treiber auf die neueste Version aktualisiert (0.1.215)?
   
   Wenn man eine bestehende Windows 10 Installation updatet, muss man bei dem Update vermutlich auch explizit die VirtIO Treiber für Windows 11 auswählen und installieren.
3. Probiere mal die QEMU-Option "-vga virtio" und installiere auch den Red Hat Treiber (falls bisher nicht gemacht).
   
   Ich hatte zuerst nur "-vga std" und "-vga cirrus". Das funktioniert gut unter Windows 10 - aber unter Windows 11 habe ich damit nur eine Auflösung von 800x600 Punkten bekommen. Erst nach dem Wechsel auf "-vga virtio" und der Installation des Red Hat VirtIO Treibers konnte ich zwischen mehreren unterschiedlichen Bildschirmauflösungen wählen. Windows zeigt als Treiber an: "Red Hat VirtIO GPU DOD controller". Denn Tipp habe ich von dieser Webseite.
4. In Deinem Script könntest Du noch eine if-Abfrage um den setpm-Befehl hinzufügen. Sonst wird das Programm swtpm bei mehrfachem Aufruf des Scripts mehrfach gestartet und läuft dann auch mehrfach parallel auf Deinem Rechner:

   Code: Select all

   if ! test -f "$(pwd)/tpm/swtpm-sock" 
   then
       swtpm socket -d -t --tpm2 --tpmstate dir="$(pwd)/tpm" --ctrl type=unixio,path="$(pwd)/tpm/swtpm-sock" 
   fi

5. Nochmals vielen Dank für Deine schöne Auflistung der QEMU-Parameter! Das hat es für mich wesentlich einfacher gemacht!

[firefly]

Mit ein paar tricks kann ma WIn11 auch ohne TPM installieren. Nur Microsoft behält sich vor, für solche systemen, welche nicht den offiziellen mindestanforderungen entsprechen, zukünftig von (sicherheits-)updates auszuschließen.

[l3u]

L3u – mit nem "L" ;-) Blöde nicht-serife Schriftarten …

In Deinem Script könntest Du noch eine if-Abfrage um den setpm-Befehl hinzufügen. Sonst wird das Programm swtpm bei mehrfachem Aufruf des Scripts mehrfach gestartet und läuft dann auch mehrfach parallel auf Deinem Rechner:

Code: Select all

if ! test -f "$(pwd)/tpm/swtpm-sock" 
then
    swtpm socket -d -t --tpm2 --tpmstate dir="$(pwd)/tpm" --ctrl type=unixio,path="$(pwd)/tpm/swtpm-sock" 
fi

Den Check braucht es nicht, wenn man swtpm mit dem Parameter -t startet, dann wird der daemonisierte Prozess automatisch beendet, wenn man die VM herunterfährt (aus der manpage):

Code: Select all

       -t|--terminate
           Terminate the TPM after the client has closed the connection.

vga virtio hab ich schon benutzt. Was mich irritiert hat, war, dass sich WhyNotWin11 danach immer noch beschwert hatte, dass mein System Windows 11 nicht ausführen könnte. Aber da ja mittlerweile Windows Update selber sagt, dass alles gut ist, wird's schon klappen.

Ich versuche jetzt einfach mal, das verlinkte Windows-11-Installationsmedium zu booten. Und dann schaumermal ;-)

Mit ein paar tricks kann ma WIn11 auch ohne TPM installieren. Nur Microsoft behält sich vor, für solche systemen, welche nicht den offiziellen mindestanforderungen entsprechen, zukünftig von (sicherheits-)updates auszuschließen.

Wobei das ja tatsächlich überhaupt kein Problem ist. Man muss ja nur swtpm installieren und qemu die passenden Optionen mitgeben. Das lief bei mir sozusagen "out of the box".

[l3u]

Update: Gebootet, Installationsmedium eingelegt, Das Setup darauf gestartet.

Nach dem Kaffeetrinken hatte ich Windows 11.

Scheint zu laufen :-)

[l3u]

Jetzt muss ich dieses Thema ein Jahr später tatsächlich nochmal ausgraben ;-)

Ich hab kürzlich mal versucht, reproduzierbar eine Windows-10-VM auf Windows 11 upzudaten. Dabei ist dann rausgekommen, dass man gar keine VirtIO-Graphikkarte braucht. Nur GPT/EFI und Secure Boot. Und eine CPU, die Windows 11 mag.

Also unterm Strich:

• Wiederherstellungsmodus booten
• Konsole aufmachen
• mbr2gpt /validate /allowFullOS
• mbr2gpt /convert /allowFullOS
• ausschalten

Und dann das Start-Script anpassen:

Vor dem QEMU-Aufruf TPM starten:

Code: Select all

swtpm socket -d -t --tpm2 --tpmstate dir=$(pwd)/tpm --ctrl type=unixio,path=$(pwd)/tpm/swtpm-sock

Dann die "machine" in q35 ändern, z. B.

Code: Select all

-machine pc-q35-7.2,smm=on,accel=kvm \

Und den TPM- und EFI-Kram einbinden:

Code: Select all

-chardev socket,id=chrtpm,path=$(pwd)/tpm/swtpm-sock \
-tpmdev emulator,id=tpm0,chardev=chrtpm \
-device tpm-tis,tpmdev=tpm0 \
-global driver=cfi.pflash01,property=secure,value=on \
-global ICH9-LPC.disable_s3=1 \
-drive if=pflash,format=raw,unit=0,file=/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \

Und dann halt noch die CPU. In meinem Fall ging nichts außer "host", also:

Code: Select all

-cpu host \

So weit, so gut. Danach kann man dann einfach ein bei Microsoft erhältliches Windows-11-ISO einbinden und das Update starten.

Edit: Ich teil das lieber mal in zwei Posts auf ;-)

[l3u]

ABER

Unter Windows 10 habe ich mit der Standard-Graphikkarte (keine Kommandozeilenoption gesetzt) folgende Auflösungen zur Auswahl:

Code: Select all

1920 x 1200
1920 x 1080
1680 x 1050
1600 x 1200
1440 x 900
1280 x 900
1280 x 1024
1280 x 960
1280 x 800
1024 x 768
800 x 600

Unter Windows 11 ist es nur noch eine einzige Option, die ich nicht ändern kann:

Code: Select all

1280 x 800

Wenn man die Graphikkarte auf VirtIO umstellt, und die entsprechenden Treiber installiert, dann gibt es ein paar mehr Auflösungen:

Code: Select all

2560 x 1600
1920 x 1080
1280 x 1024
1024 x 768
800 x 600

Aber eben viel weniger.

Bekommt man irgendwie die anderen Auflösungen auch mit VirtIO hin? Oder sogar mit der Standard-Graphikkarte? Insbesondere 1440 x 900 wäre toll, da passt die VM auf einem Full-HD-Display schön in ein Fenster …

[l3u]

Lang ist's her, aber jetzt hab ich eine potenzielle Lösung gefunden:

Wenn man im QEMU-Fenster „View“ → „Zoom To Fit“ aktiviert, und dann das Fenster auf die gewünschte Größe einstellt, und dann die Virtio-Treiber neu installiert (CD einbinden, virtio-win-gt-x64.msi starten, „Repair“ auswählen), dann wird die Bildschirmauflösung zurückgesetzt, aber man bekommt eine zusätzliche Option für die Auflösung, die exakt der Fenstergröße beim Installieren entspricht.

Damit ist dann das Problem gelöst, dass man die virtuelle Maschine schön in einem Fenster anzeigen kann. Wenn auch etwas seltsam …

[Dragonix]

Hallo,
nachdem ich eigentlich seit Ewigkeiten ausschließlich qxl verwendet habe, hab ich neulich auch mal mit virtio vga/gpu rumgespielt. Da hatte ich aber auch Probleme mit der Auflösung: 4k klappt zwar scheinbar mittlerweile, aber ich hab nur die Auswahl aus einigen vorgegebenen Auflösungen. Auch das automatische Setzen der Auflösung, das erst nach Tricks funktionierte [1], wählt nur aus diesen Standardauflösungen (zumindest bei mir). Deswegen bin ich wieder zurück zu qxl, hier funktioniert (ebenfalls in Kombination mit spice) das automatische Setzen der Auflösung (nach Installation der spice Gasttools und dem qxldod Treiber) perfekt - die Auflösung wird genau auf das gesetzt, was im Fenster angezeigt wird, ohne Skalierung/schwarze Ränder. Einziger Bug: Den Viewer muss man unter x11 starten (GDK_BACKEND=x11 spicy), unter Wayland werden viel zu große Auflösungen an die VM gemeldet, dann ist alles viel zu klein...

Falls ich wieder mehr mit der VM machen müsste, würde ich vermutlich mal wieder den Weg über RDP anschauen. Das lief früher, meine ich, am besten.

Viele Grüße
Matthias

[1] https://kevinlocke.name/bits/2021/12/10 ... o-libvirt/ unter "It requires additional work to configure automatic resolution switching, which is not done by the installer (virtio-win/virtio-win-guest-tools-installer#32). From Bug 1923886"

[schmidicom]

Wenn man eine spice basierte Konsole mit virtio vga/gpu hat gibt es nicht nur bei der Auswahl oder dem automatischen anpassen der Auflösung Probleme. Die Performance ist dann generell derart schlecht das sogar die Bewegung der Maus davon betroffen ist. Ich hoffe sehr das da bald ein Windows-Treiber raus kommt mit dem es nicht nur funktioniert sondern auch flüssig bedient werden kann, denn mit einem Linux als Gast ermöglicht die virtio vga/gpu jedenfalls ein richtig geiles Erlebnis.