2
Hyper-V-Umzug auf QEMU-KVM - Datenträger nicht erkannt
Hallo,
ich hatte heute bereits ein Problem mit der Einbindung von TPM 2.0 in QEMU/KVM, welches aber gelöst wurde: Hyper-V-Maschinen mit Windows 11 Pro auf QEMU-KVM portieren
Meine Aufgabenstellung besteht darin, drei virtuelle PCs mit Windows 11, die bisher unter Hyper-V laufen, auf QEMU/KVM unter Ubuntu Server 24.04 zu portieren.
Folgende Schritte habe ich bisher unternommen:
1. Virtuelle Festplatte komprimiert und als feste Disk eingestellt (da unter QEMU/KVM aus Geschwindigkeitsgründen das RAW-Format genutzt werden soll).
2. Konvertierung der virtuellen Festplatte in das RAW-Format:
3. UEFI-Daten speichern:
4. Virtuelle Maschine erstellen und die konvertierte Festplatte einbinden:
Danach habe ich ein paar Einstellungen vorgenommen, um das TPM 2.0 einzustellen.
Im UEFI-BIOS sehe ich, dass sowohl TPM 2.0 als auch Secureboot aktiv sind.
Beim Start der VM startet Windows 11 nicht – stattdessen lande ich in der Reparaturkonsole oder im BIOS, aber Windows selbst bootet nicht.
Ich kann im Reparaturmodus in die Konsole wechseln und diskpart ausführen – es wird nichts gefunden.
Jetzt stehe ich auf dem Schlauch und bin mir gar nicht mehr sicher, wie vorgehen. Jeder Hinweis von euch würde mich sehr freuen.
Danke und lG
René
ich hatte heute bereits ein Problem mit der Einbindung von TPM 2.0 in QEMU/KVM, welches aber gelöst wurde: Hyper-V-Maschinen mit Windows 11 Pro auf QEMU-KVM portieren
Meine Aufgabenstellung besteht darin, drei virtuelle PCs mit Windows 11, die bisher unter Hyper-V laufen, auf QEMU/KVM unter Ubuntu Server 24.04 zu portieren.
Folgende Schritte habe ich bisher unternommen:
1. Virtuelle Festplatte komprimiert und als feste Disk eingestellt (da unter QEMU/KVM aus Geschwindigkeitsgründen das RAW-Format genutzt werden soll).
2. Konvertierung der virtuellen Festplatte in das RAW-Format:
qemu-img convert -O raw BUERO4_fix.vhdx /mnt/data/vms/buero4/buero4.raw -p3. UEFI-Daten speichern:
cp /usr/share/OVMF/OVMF_VARS_4M.ms.fd /mnt/data/vms/buero4/buero4_VARS.fd4. Virtuelle Maschine erstellen und die konvertierte Festplatte einbinden:
virt-install \
--name buero4 \
--memory 8192 \
--vcpus 8 \
--cpu host \
--machine q35 \
--boot loader=/usr/share/OVMF/OVMF_CODE_4M.secboot.fd,loader.readonly=yes,loader.type=pflash,loader.secure=yes,nvram=/mnt/data/vms/buero4/buero4_VARS.fd \
--disk path=/mnt/data/vms/buero4/buero4.raw,format=raw,bus=virtio \
--network bridge=br0,model=virtio \
--graphics spice,listen=0.0.0.0 \
--video qxl \
--channel unix,target.type=virtio,name=org.qemu.guest_agent.0 \
--virt-type kvm \
--os-variant=win11 \
--memorybacking hugepages=on \
--import \
--boot hd \
--noautoconsoleDanach habe ich ein paar Einstellungen vorgenommen, um das TPM 2.0 einzustellen.
Im UEFI-BIOS sehe ich, dass sowohl TPM 2.0 als auch Secureboot aktiv sind.
Beim Start der VM startet Windows 11 nicht – stattdessen lande ich in der Reparaturkonsole oder im BIOS, aber Windows selbst bootet nicht.
Ich kann im Reparaturmodus in die Konsole wechseln und diskpart ausführen – es wird nichts gefunden.
Jetzt stehe ich auf dem Schlauch und bin mir gar nicht mehr sicher, wie vorgehen. Jeder Hinweis von euch würde mich sehr freuen.
Danke und lG
René
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672179
Url: https://administrator.de/forum/hyper-v-umzug-auf-qemu-kvm-datentraeger-nicht-erkannt-672179.html
Ausgedruckt am: 29.03.2025 um 23:03 Uhr
2 Kommentare
Neuester Kommentar
Moin,
Hast Du mal einfach mal versucht, mit einer "Notfall-ISO" wie z.B. knoppix, ct-notfallwindows, HBCD, etc., direkt aus der Kommandozeile zu booten und nachzuschauen?
Ungefähr so:
Dann sieht man zumindest, ob das Notafllsystem die "HD" sieht und ob man darauf zugreifen kann.
Wenn ja, dann mit passenden parametern in der Kommandozeile mit der Widn11-Setup-ISO aufrufen, um zu schauen, ob dann das Image gesehen wird.
Generell würde ich raten, zum debugen erst alles in der shell auszuprobieren und dann erst in die Konfigdatei z uschreiben, wenn es funktioniert.
lks
Hast Du mal einfach mal versucht, mit einer "Notfall-ISO" wie z.B. knoppix, ct-notfallwindows, HBCD, etc., direkt aus der Kommandozeile zu booten und nachzuschauen?
Ungefähr so:
kvm -hda -/mnt/data/vms/buero4/buero4.raw -cdrom /pfad/zur/notfall.iso -boot order=dc
Dann sieht man zumindest, ob das Notafllsystem die "HD" sieht und ob man darauf zugreifen kann.
Wenn ja, dann mit passenden parametern in der Kommandozeile mit der Widn11-Setup-ISO aufrufen, um zu schauen, ob dann das Image gesehen wird.
Generell würde ich raten, zum debugen erst alles in der shell auszuprobieren und dann erst in die Konfigdatei z uschreiben, wenn es funktioniert.
lks
Danke! Ich habe weitergeforscht und dabei einen Fehler meinerseits entdeckt: Ich habe voreilig die VM mit den virtio-Treibern erstellt. Somit kommt die VM nicht auf ihren Datenträger. In der Eingabeaufforderung der Wiederherstellungskonsole habe ich dann manuell den Disk-Treiber geladen und ich konnte an den Datenträge kommen.
Um die Sache nicht weiter zu verkomplizieren, habe ich den Datenträger an den virtuellen SATA-Controller angeschlossen und somit konnte ich endlich in Windows booten. Darin habe ich alle virtio-Treiber installiert und nachgeschaut, das der Gerätemanager sauber bleibt.
Danach heruntergefahren und die Konfiguration insofern angepasst, dass der Datenträger an den SCSI-Bus angeschlossen wird:
Leider gelingt mir die Einbindung der VirtIO-SCSI-Disk-Treiber in Windows nicht vollständig. Ich sollte im Gerätemanager unter Laufwerke "Red Hat VirtIO SCSI Disk Device" haben, leider aber immer noch "QEMU QEMU HARDDISK SCSI Disk Device".
Unter Speichercontroller sollte m. E. alleine "Red Hat VirtIO SCSI pass-through controller" stehen, es gibt aber noch den Eintrag "Microsoft-Controller für Speicherplätze".
Wenn das auch behoben ist, wäre ich durch.
Um die Sache nicht weiter zu verkomplizieren, habe ich den Datenträger an den virtuellen SATA-Controller angeschlossen und somit konnte ich endlich in Windows booten. Darin habe ich alle virtio-Treiber installiert und nachgeschaut, das der Gerätemanager sauber bleibt.
Danach heruntergefahren und die Konfiguration insofern angepasst, dass der Datenträger an den SCSI-Bus angeschlossen wird:
...
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
<source file='/mnt/data/vms/test/test.raw'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
...
<controller type='scsi' index='0' model='virtio-scsi'>
<driver queues='8'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>
...Leider gelingt mir die Einbindung der VirtIO-SCSI-Disk-Treiber in Windows nicht vollständig. Ich sollte im Gerätemanager unter Laufwerke "Red Hat VirtIO SCSI Disk Device" haben, leider aber immer noch "QEMU QEMU HARDDISK SCSI Disk Device".
Unter Speichercontroller sollte m. E. alleine "Red Hat VirtIO SCSI pass-through controller" stehen, es gibt aber noch den Eintrag "Microsoft-Controller für Speicherplätze".
Wenn das auch behoben ist, wäre ich durch.
