Qemu mit HAX acceleration unter NetBSD 9.0

franco98

NetBSDler aus Leidenschaft
Hallo NetBSD Freunde,

ich habe gerade erfolgreich aus den neusten pkgsrc/wip sources qemu mit HAX Unterstützung gebaut. Das entsprechende NetBSD kernel Modul habe ich ebenfalls erfolgreich aus dem ganz frischem haxm-7.5.6 source compiliert und ohne Probleme laden können.

Ziel ist es eine hardwarebesschleunigte Virtualisierung unter NetBSD zu erstellen, mit Windows als Guestsystem z.B. .

Sobald ich weiter bin stelle ich die Infos hier rein und die packages von qemu und das Kernel Modul haxm.kmod. ebenfalls. Das Erstellen der HAXM devices sollte auch kein Problem sein, ich habe einiges im Netz gefunden.

Bis dahin...
Franco
 
So es ist vollbracht, das package für qemu mit HAXM-Unterstützung und das Kernel-Modul sind auf meinem Archiv zum Download und Testen. Wer lieber alles selber bauen will, hier eine kurze Anleitung.

Ich bin auf Qemu mit Haxm Unterstützung über diesen Heise Artikel gekommen. Da ich das mal ausprobieren wollte, suchte ich weiter.
Folgendes benötigt man:

1. Das Kernel Modul haxm, hier zu holen: HAXM , z.B. mit git clone https://github.com/intel/haxm
2. Das Modul bauen: cd platforms/netbsd und dann make
3. Das Modul bereit stellen: mkdir -p /stand/amd64/9.0/modules/haxm und cp haxm.kmod /stand/amd64/9.0/modules/haxm/
4. Das Modul beim Start laden: in die /etc/modules.conf haxm eintragen
5. Das Modul laden: reboot oder gleich modload haxm

Nun Qemu mit haxm bauen

1. Die wip sources in /usr/pkgsrc integrieren: cd /usr/pkgsrc und git clone git://wip.pkgsrc.org/pkgsrc-wip.git wip
2. Qemu bauen: cd /usr/pkgsrc/wip/qemu-git und make install clean clean-depends

Ich musste nach dem 1. Bauen die PLIST anpassen, da Teile der Manpages nicht dabei waren und einige andere Programmteile dafür dazu kamen. Beim zweiten make install baute es alles fertig und installierte mir das package.

Nun noch die HAXM devices erstellen. Ich habe im Internet folgende Zeilen gefunden, die dafür relevant sind:

1. mknod /dev/HAX c 348 0
2. mkdir /dev/hax_vm

Nun noch den Rest:
1. for i in `seq 0 7`; do mkdir /dev/hax_vm0$i; done
2. for i in `seq 0 7`; do mknod /dev/hax_vm/vm0$i c 349 $i; done

3.
i=0
while [ $i -lt 128 ]; do
vm=$(echo "$i/16"|bc)
vcpu=$(echo "$i%16"|bc)
echo "i=$i vm=$vm vcpu=$vcpu"
cmd=$(printf "mknod /dev/hax_vm%02d/vcpu%02d c 350 %d" $vm $vcpu $i)
$cmd
let "i+=1"
done


Das war's. Nun könnt ihr qemu mit haxm starten, z.B. ein

sudo qemu-system-i386 -boot d -cdrom NetBSD-9.0-i386.iso -m 1024m -name "NetBSD" -hda hdd.img -accel hax

startet eine NetBSD 9.0 i386 Installation auf einer hdd.img die ich zuvor mit qemu-img create -f qcow2 hdd.img 51200M erstellt habe.

Einige Bemerkungen:
Man benötigt zum Bauen des Moduls die src-, xsrc- und syssrc-Sets. Ich habe qemu mit gtk3 und sdl gebaut, also

PKG_OPTIONS.qemu= gtk3 sdl in der /etc/mk.conf

Frühere qemu Installationen müssen entfernt werden und die neue, HAXM-Qemu Version ist kleiner, also 3.0xxx statt 4.2.xxx.

Viel Spaß und bitte berichtet von Euren Erfahrungen!

VG aus LE
Franco
 
Qemu.png
 
Danke für die Anleitung und die packages.
Nun hab ich noch nie mit VMs gearbeitet oder gespielt und frage mich, wie leistungsfähig eine Maschine sein muss, auf der 3-4 VMs laufen.
 
Ein alter i5 mit vier Kernen und 8GB RAM reichen bei mir hier schon. Mehr geht natürlich immer.

Ich kompiliere das qemu aus dem pkgsrc (nicht wip) gerade neu, es scheint bei geladenen Kernelmodul haxm auch mit diesem Support zu bauen. Wäre natürlich super ein neueres Binary zu haben.
 
Danke für die Anleitung und die packages.
Nun hab ich noch nie mit VMs gearbeitet oder gespielt und frage mich, wie leistungsfähig eine Maschine sein muss, auf der 3-4 VMs laufen.

Grundsätzlich sollte er, wohl auch bei dieser Lösung, Hardwarevirtualisierung können.

Die Virtualisierungen brauchen immer ein kleines bisschen "Zusatzleistung" ontop von wenigen einstelligen prozent bis zu niedrigen 2-Stellingen Prozentzahlen, je nach dem was man macht und welche virtualisierungslösung man verwendet.

Der rest ist "Kommt drauf an" - hast du nen Rechner der eh nur 5% CPU & 20% Ramauslastung hat, und du startest dann 4 maschinen die zusammen nochmal 40% des Rams belegen und und auch kaum CPU, reicht der rechner, brauchen alle maschinen mehr als 100% des RAMS und lasten den Prozessor ständig völlig aus wird das ganze sehr langsam werden.

Halt abhängig von der Software.
 
Villeicht nen etwas praxisnäheres Beispiel:

Ich habe einen, auch nicht mehr taufrischen, AMD-FX-8350 mit 16GB Ram unter Windows 10, auf dem Windows läuft das langweilige "Virtual Box" als virtualisierungslösung.

Ich kann problemlos gleichzeitig:

  • Das Host-OS für Browsen & Netflix u.ä. nutzen
  • Eine Debian-VM starten mit vollen Desktopbetrieb (6GB Ram)
  • Zwei OpenBSD VMs mit nem "Bastelwebserver" und sowas mit je 2GB Ram starten
Und das alles läuft absolut flüssig, egal ob die Anwendungen vom host-os oder die in den VMs. Das ist auch so grob mein Use-Case hier.

Starte ich allerdings auf dem Host ein aktuelleres, leistungs-hungriges PC-Spiel das auch ohne VMs schon allen RAM und die gesamte CPU belegt, wird das nicht mehr sinnvoll funktionieren.

Genauso auch wenn ich der Debian VM 12 GB Ram und alle Prozessorkerne gebe und dann irgendwas starte was die CPU zu 100% auslastet. Dann wird auch der rest des systems inkl. des Host-OS merklich langsamer laufen.

Das meine ich mit "Es kommt etwas drauf an was man dann genau macht", also wie viel Ram die VMs bekommen, was in den VMs an Software läuft und letztendlich auch was auf dem Host ggf. noch an Software läuft.
 
Kurzer Nachtrag:

Ich habe qemu aus dem pkgsrc neu gebaut und hochgeladen, es läuft sowohl mit haxm als auch mit mvmm als Accelerator. Man muss je nach Wunsch das Kernel Modul in die /etc/modules.conf eintragen und die VM neu starten. Beide starten ein frisch aufgesetztes Windows ohne Probleme, zur Stabilität kann ich noch nichts sagen.

Wichtig! Man muss nicht das qemu aus den wip nehmen, also nur das Modul bauen. Der neue Qemu scheint die Patches schon drin zu haben.

VG aus LE
Franco
 
Danke @franco98 und @CommanderZed. Ich komme zu dem Schluß, dass ich meinen schwächlichen NetBSD-Laptop damit nicht belasten werde. Werd mal schauen, ob NetBSD 9 auf einem der Nucs mit i5 und 16 GB läuft .
Wenns klappt, werd ich OpenIndiana, ein altes Interactive und Windows als VMs aufsetzen. Dann hätte ich nach Windows 3.0 doch noch mal ein MS-Betriebssystem - nur, um nicht völlig raus zu kommen. :cool:
 
@berni51
Von Windows 3 zu Windows 10 ist ja zum Glück nicht viel passiert . Ansonsten muss man ja nicht virtualisieren, es reicht ein zweiter Rechner.

Ich wollte nur zeigen, dass NetBSD noch lange nicht tot ist und noch vieles Interessantes anbietet.

Schönes WE
 
Ich würde doch niemals einen Rechner für Windows opfern! :rolleyes:

Ach ja: Jetzt mit der 9er glaube ich auch, dass NetBSD nicht tot ist.
 
@berni51
Nun ja ich für meinen Teil kann fast alles mit NetBSD machen, bis auf:

1. per Filemanager und MTP auf meine Smartphones zugreifen
2. per adb und fastboot auf dieselben dann Firmware einspielen
3. mit dem Source von AOSP eigene Firmware erstellen und testen
4. Android Firmware-Images mounten und bearbeiten (ext4 FS), usw.

Dafür brauche ich aktuell noch einen Windows oder / und Linux-PC, manches geht nur mit Windows, anderes nur mit Linux. Das alles unter NetBSD wäre ein Traum. Ich arbeite statt dessen an einer Lösung mit Hilfe der o.g. Virtualisierungen. Falls ich die USB-Verbindungen nativ vom NetBSD Host an die Linux- und Windows-Clients weiterreichen kann, sollten diese die angeschlossenen Smartphones erkennen und ich kann so zugreifen.

Unter Linux als Host mit Oracles Vbox ging das, ob es mit Qemu unter NetBSD geht weiß ich nicht. Mir war aber erstmal wichtig zu testen, wie gut ich unter NetBSD virtuelle OS installieren kann und ob sie schnell und stabil laufen.

Die Antwort darauf lautet JA.
 
Eins meiner X61 hat Windows 10 ... Rechner die Windows 10 fähig sind gibts doch auffen Schrott* ... ... einfach mal machen :)

So schlimm wie zu '98 oder XP Zeiten ist MS garnicht mehr ... schon seit 7 eigentlich imho - auch wenns auch bei MS natürlich gewisse ... dinge gibt die einen nicht so gefallen, aber letztendlich gibts an OpenBSD, Linux und für mich gerade neu NetBSD auch das ein oder andere wo es noch luft nach oben gibt :)

Das ist nicht tot das ewig lebt, bis das der tot die Zeit besiegt :) (SCNR)

*(Jaja, ich weiß, ich wiederhole mich da, mich wunderts nur immer wieder hier das hier leute schreiben das sie "kaum nen Rechner haben der xyz halbwegs kann" oder versuchen auf biegen und brechen irgendwelche Hardware zu verwenden die es nicht mal mehr auf dem Recyclinghof gibt, obwohl es X mal neuere gibt die sonst auch verschrottet wird für Lau oder den gegenwert eines Dönertellers - und das nicht aus spaß an der Freud an alter Hardware sondern aus ... keine Ahnung)
 
Um den Thread nicht unnötig in die Länge zu ziehen, hier ein kurzes Fazit:

Mit dem neusten Qemu aus current und dem Kernel-Modul nvmm kann man sehr gut und stabil eine Virtualisierung unter NetBSD betreiben. Man kann alternativ das haxm Modul wie oben beschrieben bauen und benutzen, es ist aber weniger gut in den Kernel integriert als das eigene nvmm.

In Bezug auf die Geschwindigkeit beim Ausführen merke ich keine Unterschiede, es läuft aber nicht so stabil wie nvmm.

Vielleicht ändert sich das noch, ich nehme aktuell nun für meine Vorhaben nvmm.
 
Zurück
Oben