Virtualization Station - UEFI VM nach Änderung an VM-Konfiguration wieder Bootfähig machen

  • Hallo zusammen,


    UEFI hat so einige Vorteile (allen voran der Boot von GPT Formatierten Partitionen, sprich mehr als 2 TB), auf die ich hier nun aber nicht eingehen möchte. Das hier soll nur eine sehr kurze "Information" sein, für die, die genau das versuchen. Was genau ist "das"? Windows oder Linux per UEFI/OVMF zu starten.

    Vor einiger Zeit habe ich auf einem TS-877XU-RP zwei Virtuelle Windows 2012 R2 installiert. Aus verschiedenen Gründen "mussten" diese UEFI haben. QNAP bietet das in den Einstellungen nicht an, da das System aber auf QEMU/KVM basiert und QNAP im Prinzip die fertigen Pakete genommen hat, kann man z.B. eine mit UEFI in VirtualBox gebaute Virtuelle Maschine relativ problemlos importieren.


    Probleme gibt's aber wenn man z.B. etwas an der Maschine ändert. Festplatte vergrößert, mehr Arbeitsspeicher oder ähnliches. Denn QNAP hält sich da nicht so ganz an das, was das QEMU/KVM Manual vorgibt und schreibt die XML-Konfigurationen "zweimal".

    QNAP schmeißt dann den Befehl, dass die Virtuelle Maschine per UEFI bootet einfach aus der Konfiguration und man bekommt von SeaBios die schöne Meldung "No bootable devices found". Logisch, UEFI bootet per GPT und nicht per MBR.


    Hier kurz die Schritte, um das ganze wieder gerade zu ziehen (oder aber um direkt auf dem NAS eine Maschine mit UEFI-Boot einzurichten - oder sogar "ordentliches" PCIe-Passthrough zu machen, wofür i440FX nicht benutzt werden sollte)


    • Per SSH auf das NAS Verbinden
    • export LD_LIBRARY_PATH=/QVS/usr/lib:/QVS/usr/lib64/ export PATH=$PATH:/QVS/usr/bin/:/QVS/usr/sbin/ eintippen/einfügen, damit die virsh befehle erkannt werden
    • mit virsh list -all herausfinden, welche Virtuelle Maschine man überhaupt bearbeiten möchte. QVS benutzt dafür nicht die eigentlichen Namen der VMs, sondern die UUIDs. Die stehen auch im Intereface der Virtualization Station
    • mit virsh edit VMName/UUID öffnet sich VIM und man kann die XML-Datei die QEMU benutzt direkt editieren. Aus mir unerfindlichen Gründen werden die Änderungen an der XML-Datei im Ordner der VM auf der Festplatte ignoriert.
    • In VIM scrollt man dann zur Zeile mit <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type>. Das ist übrigens auch die Zeile, in der man den Maschinen Typ ändern kann - also ob i440FX oder Q35. Die Zeile müsste dann <type arch='x86_64' machine='pc-q35-2.3'>hvm</type>" heißen. Dadurch möchte aber z.B. ein schon laufendes Windows noch mal aktiviert werden. Das reale äquivalent wäre ein Wechsel des Mainboards. Daher hab ich das bis jetzt noch nicht auf dem QNAP ausprobiert (auf Proxmox und anderen Hypervisors aber sehr wohl, das funktioniert dort)
    • Nun fügt man unter diese Zeile noch <loader type='rom'>/QVS/usr/share/qemu/OVMF.fd</loader> ein. Diese Zeile fliegt bei jeder Änderung der VM einfach raus.
    • VIM Befehle sind "i" um etwas direkt an die Cursorposition zu schreiben, ESC um aus dem Edit-Modus wieder heraus zu kommen und ":x" um die geänderte Datei zu speichern.


    Damit lässt sich die Maschine wieder starten und man bekommt statt SeaBios, TianoCore zu sehen. Dazu muss man aber auch noch erwähnen, dass die LibVirt Version die QNAP benutzt steinalt ist und das ganze inzwischen anders funktioniert bzw. deutlich einfacher ist.


    Nexusband

  • Ist das so noch aktuell? Ich kann doch jetzt wohl in der Weboberfläche UEFI wählen. Muss man da dann jetzt auch neu aktivieren?


    Besonders interessiert mich auch die Aussage "ordentliches" PCI-Passthrough. Was bedeutet das. Damit kämpfe ich schon Jahre.


    EDIT: Vielleicht hat sich meine Hoffnung schon damit zerschlagen:

    ...

    Einschränkungen

    Da die heruntergeladene Windows 10-VM von Microsoft auf einem UEFI-BIOS basiert, gibt es zwei Einschränkungen für die VM:

    • AMD-Grafikkarten werden von GPU-Pass-Through nicht unterstützt

    (Hab' ich eventuell jetzt erstmals die Zitatfunktion selber richtig genutzt?)

    Einmal editiert, zuletzt von duke-f ()

  • Jain - mit den neuen Versionen ist das so nicht mehr Aktuell, weil das Phänomen einfach nicht mehr auftritt. Da UEFI jetzt nativ unterstützt wird, wird der Teil auch nicht aus der Config gelöscht.


    Das mit dem PCIe-Passthrough ist sowieso so eine Sache...das ist "Hit and miss", AMD Grafikkarten kann man sehr wohl durchleiten (IMHO auch deutlich einfacher, als NV-Karten), bis einschließlich der RX5700/WX5700 gibt's allerdings einen "Bug", bei dem man beim neustarten der VM auch den Hypervisor neustarten muss (in dem Fall das komplette NAS).


    Auf Debian/Proxmox kann man das umschiffen, auf dem QNAP eher schlecht, weil die KVM/QEMU Versionen relativ alt sind.

  • Konkret habe ich ja eine RX480, die ich eben auf meine Win10 VM durchschleife. "Hit and mIss" kann ich da bestätigen: Mal klappt der Neustart, mal muss ich das NAS komplett neu starten. Interessant ist aber, dass die VM auch im Fehlerfall (mit gelbem Warnzeichen im Gerätemanager) durchaus auf die Karte zugreift. Ich bekomme das Bild nämlich auf den angeschlossenen Monitor. Nur kann ich eben die Auflösung beispielsweise nicht voll nutzen. MItlerweile habe ich aber eine PCIe-USB-Karte (nach Kompatibilitätsliste gekauft, QNAP-Entwicklung sagte jetzt aber, es sein keine Original, der Händler wiederum sagt doch ...), für diese muss ich immer einen Neustart des NAS durchführen, wenn die VM neu gestartet wird und ich sie wieder nutzen will.


    Hab' Mal probehalber versucht, ein brachliegendes WIn10 einfach in der Konfiguration auf UEFI zu ändern ... hat in einer für mich nicht wirklich nutzbaren Shell geendet. Vielleicht muss ich dazu dann eine VM komplett neu anlegen.

  • Hab' Mal probehalber versucht, ein brachliegendes WIn10 einfach in der Konfiguration auf UEFI zu ändern ... hat in einer für mich nicht wirklich nutzbaren Shell geendet. Vielleicht muss ich dazu dann eine VM komplett neu anlegen.

    Genau das Problem habe ich auch.

  • Du müsstest das Laufwerk der Win-VM vorher umstellen - frag jetzt nicht wie, irgendwo ist beschrieben, wie das sozusagen „on the fly“ geht. Ist ewig her…


    Stichwort dazu für die Recherche: MBR2GPT-Tool von Microsoft.

  • Ich habe mich da jetzt durchgekämpft. Um die VirtIO-Treiber für die Disks zu verwenden muss man zwingend ein UEFI-BIOS haben.

    Das kann man alles in der Virtuellen Maschine einstellen und auch die VirtIO-Treiber installieren.


    Aber dennoch klappt der Boot nicht, weil das UEFI-BIOS zwingend eine GPT-Partition Table benötigt. Und wenn man Windows in der VM installiert, dann wurde bei mir ein normales BIOS installiert. Man kann das theoretisch mit dem MBR2GPT.EXE in der Windows-Installation konvertieren. Aber ich habe das nicht geschafft. Ich brauche die Platten dort nicht, darum habe ich es gelassen.


    Auf einem zweiten NAS habe ich WIN11 installiert und da habe ich bei der Installation die ISO-Datei von Windows in der CD gegen die Treiber-CD ausgetauscht und die Treiber zur Installation vorinstalliert. Und siehe da, es klappt. Die Performance ist extrem spürbar gestiegen.