Virtuelle Maschine unter FreeBSD+bhyve UND Linux+qemu/kvm laufen lassen?

Rosendoktor

Well-Known Member
Hallo,

kann man ein (in meinen Fall jetzt gerade Windows Server 2019) Image erstellen, das auf einer Dual Boot Maschine mit Debian 10 und FreeBSD 12 unter beiden Betriebssystemen als VM gestartet werden kann? Wenn ja, wie genau?

Hab' unter Debian mit dem virt-manager ein raw Image erstellt, Windows Server 2019 installiert und dieses bootet auch, aber unter FreeBSD bekomme ich im virt-manager die Fehlermeldung "unsupported image type" wenn ich dieses Image in einer neuen virtuelle Maschine einrichten und starten will.

Grüße,

Robert
 

Andy_m4

Well-Known Member
virt-manager die Fehlermeldung "unsupported image type" wenn ich dieses Image in einer neuen virtuelle Maschine einrichten und starten will.
Ich hab den Eindruck der virt-manager läuft mit bhyve noch nicht so ganz rund. Ich hab es auch nie zum laufen gekriegt. Also nicht mal eine frische virtuelle Maschine erstellt.
Evtl. müsste man mal testen, ob sich das mit bhyve direkt starten lässt (ich hoffe mal das QEMU/KVM raw Format und das bhyve Imageformat sind beide wirklich "raw" und damit identisch).

Eine Alternative zu KVM/QEMU und bhyve wäre VirtualBox.
 

Rosendoktor

Well-Known Member
Ich hab den Eindruck der virt-manager läuft mit bhyve noch nicht so ganz rund. Ich hab es auch nie zum laufen gekriegt. Also nicht mal eine frische virtuelle Maschine erstellt.
Evtl. müsste man mal testen, ob sich das mit bhyve direkt starten lässt (ich hoffe mal das QEMU/KVM raw Format und das bhyve Imageformat sind beide wirklich "raw" und damit identisch).

Eine Alternative zu KVM/QEMU und bhyve wäre VirtualBox.
Da dürftest Du recht haben. Die Meldung "unsupported image type" kommt im virt-manager auch dann, wenn dieser selbst das frische Image erzeugt hat... Schade, finde den ganz angenehm zu bedienen.

Dann eben händisch... Bin noch nicht dazu gekommen das zu probieren.

Wobei ich eh Verständnisprobleme habe, wie genau so ein Image nun auszusehen hat. Mit oder ohne Partitionstabelle, MBR oder GPT, wohin soll Grub, wenn überhaupt (bhyve bringt ja seinen eigenen Grub mit), und UEFI ist nochmal komplizierter... Und letzteres braucht man wohl für grafische Ausgabe, oder auch nicht, oder... :confused: Na ja, ein Thema für lange Winterabende. ;)
 

Andy_m4

Well-Known Member
Wobei ich eh Verständnisprobleme habe, wie genau so ein Image nun auszusehen hat.
Also wenn ich richtig verstanden habe, dann ist das Image quasi 1:1 das was auf einer Platte liegen würde. Also Blöcke/Sektoren aufsteigend in der Imagedatei liegend. Also sowohl bei KVM/QEMU raw als auch bei bhyve.
Theoretisch sollte es dann sogar gehen das Du ein System zwischen den beiden teilst. Klar. Vom Partitionslayout etc. her muss es identisch sein.
Auch das Bootverfahren.
Und dann natürlich die Treiber im Gastsystem(optimalerweise die virto-Treiber).

Dann eben händisch...
Ja. Ich benutze sowieso immer bhyve direkt ohne irgendwelche Drittsoftware drumherum. Bisher hab ich damit auch alles zum laufen gekriegt was ich brauchte (inkl. Windows).
 

Rosendoktor

Well-Known Member
So verstehe ich das auch mit den raw Images, nur irgendwie bekomme ich ein manuell auf die gleiche Weise wie ein physikalisches Medium zusammengebautes Debian 10 Image nicht zum booten, bleibt im Gegensatz zu realen Platten im Grub Rescue hängen... Denke das hat damit zu tun wie Grub im MBR installiert wird, das scheint nicht so zu funktionieren wie es mit mounten+chroot usw. auf realer Platte funktioniert. Ein mit dem Debian Installer erstelltes Image bootet, und sieht exakt gleich aus im Partitionseditor.
 

Rosendoktor

Well-Known Member
Okay, um das Thema mal abzuschliessen: RAW Images, die so vorbereitet werden, dass sie von physikalischen Medien bootfähig sind, booten auch sauber unter bhyve oder qemu, auch abwechselnd. Funktioniert sowohl mit BIOS/MBR als auch UEFI/GPT, wobei qemu etwas zickig ist mit den EFI Booteinträgen bzw. Pfaden unter EFI/, bhyve scheint glücklich zu sein mit dem Standardpfad EFI/BOOT/BOOTX64.EFI. In der vm muss bei einem Linux Gast lediglich die Netzwerkkonfiguration an den Hypervisor angepasst werden, weil das Interface unterschiedliche Namen bekommt. Also alles so, wie es auch erwartet wurde.
 
Oben