Also zumindest Virtualbox (unter Windows) hat einen ziemlichen Overhead, KVM ist glaube ich relativ nah an Xen dran, ich habe damit selbst aber noch keine Erfahrungen gemacht. Generell kann ich aber sagen, das der Performanceunterschied zwischen paravirtualisierten und hardwarevirtualisierten Maschinen schon extrem ist unter XEN. Hast du KVM mit dem x86-generic-image getestet oder mit dem kvm-image?
Die Hardwarevirtualisierten kommen nur in die Nähe, wenn man (unter Windows) die entsprechenden GPLPV-Treiber installiert, die es für Linux natürlich nicht gibt, da man dort „einfach“ die passenden Kernel-Module läd. Die CPU-Last in der VM ist bei einem Speedtest auch relativ gering, allerdings läuft das Wirtsystem am Limit. Das habe ich bei meinen PV VMs bisher noch nie gesehen, die können meine Unitymedia 50/5 Leitung schon ausreizen, auch wenn ich zeitgleich einen Kernel kompiliere o.ä…
Das mag ja sein, dass Virtualbox overhead hat.
Aber wenn Xen in den dosemu-modus schaltet, dann ist es völlig aus. (Was Du ja selbst mitbekommst.)
Und ja, für xen fehlt das entsprechende Profil in gluon.
Ich habe versucht, da mal hinterherzugoogeln, aber die Doku im openwrt-wiki selbst ist nicht einmal „mau“.
Da ist also echte Forschungsarbeit angesagt.
Es beruhigt mich etwas, dass es nicht ganz so trivial ist, sonst hätte ich an meinen Fähigkeiten gezweifelt.
Ich habe mir schon ein entsprechendes Target erstellt, eigentlich sind es -nach meinem Verständnis- nur die kmod_xen_* module, die gebaut werden müssen, aber die wollten bisher nie im Image auftauchen, wenn der Build bei mir durchlief mit GLUON_TARGET=„x86-xen_domu“. Ich versuche es gerade nochmal, aber mein Server ist auch nicht mehr der jüngste, dauert also immer eine ganze Weile…
Weiß denn jemand, wie die benötigten, schnelleren Treibermodule heißen? Die in die x86-Images zu schmeißen ist kein Problem.
Haben aktuelle Desktopdistris die? Dann könnte man die Mal booten und nachsehen. Oder hängt es unter Linux schon auf der Hostseite?
Es muss ja sowohl auf der Host- als auch auf der virtuellen Seite aktiviert und korrekt konfiguriert sein, damit man mehr Performance bekommt. Wenn es nur irgendwo nicht passt, schleicht man dahin.
kmod-xen-evtchn
kmod-xen-fs
kmod-xen-kbddev
kmod-xen-netdev
wenn ich richtig im make menuconfig von Openwrt nachgeschaut habe.
In meinen VMs werden als geladene module mit xen im Namen xen_netfront, xen_blkfront und xen_pcifront angezeigt. Das ist aber auch ein 3.16.7 Kernel von Debian. Der Wirt startet die VM zwar im PV-Modus in Erwartung, dass die VM die Devices benutzt, aber die weiß leider nichts damit anzufangen ohne die Kernelmodule. Man schleicht also nicht mal mehr, man steht
EDIT: Build brach leider ab und genau da war ich auch schonmal
...
make -w -C /mnt/tmp/gluon/build/x86-xen_domu/openwrt -f /mnt/tmp/gluon/Makefile kernel
make[2]: Entering directory '/mnt/tmp/gluon/build/x86-xen_domu/openwrt'
make V=ss -C /mnt/tmp/gluon/build/x86-xen_domu/openwrt/target/linux/x86 -f /mnt/tmp/gluon/include/Makefile.target /mnt/tmp/gluon/build/x86-xen_domu/openwrt/build_dir/target-i386_i486_uClibc-0.9.33.2_gluon-x86-xen_domu/linux-x86_xen_domu/linux-3.10.49/.image TARGET_BUILD=1
make[3]: Entering directory '/mnt/tmp/gluon/openwrt/target/linux/x86'
make[3]: *** No rule to make target '/mnt/tmp/gluon/build/x86-xen_domu/openwrt/build_dir/target-i386_i486_uClibc-0.9.33.2_gluon-x86-xen_domu/linux-x86_xen_domu/linux-3.10.49/.image'. Stop.
make[3]: Leaving directory '/mnt/tmp/gluon/openwrt/target/linux/x86'
/mnt/tmp/gluon/Makefile:276: recipe for target 'kernel' failed
make[2]: *** [kernel] Error 2
make[2]: Leaving directory '/mnt/tmp/gluon/build/x86-xen_domu/openwrt'
/mnt/tmp/gluon/Makefile:289: recipe for target 'prepare' failed
make[1]: *** [prepare] Error 2
make[1]: Leaving directory '/mnt/tmp/gluon/build/x86-xen_domu/openwrt'
Makefile:69: recipe for target 'all' failed
make: *** [all] Error 2
Ich habe nur mal in das make menuconfig reingeschaut um zu wissen, wie die module heißen, geändert habe ich da nix. Habe mir dann im targets-Ordner den x86-generic kopiert als x86-xen_domu und da dann die profiles.mk angepasst. Ich probier’s jetzt aber mal mit der quick-and-dirty Lösung, die du vorgeschlagen hast
Habe dann die config im selben Verzeichnis noch erweitert um genau die Packages und der Build lief durch. Allerdings will mein Xen-Server den Kernel nicht starten, da ihm der zu normal erscheint, hab die Fehlermeldung gerade nicht mehr parat, weil nun wieder ein Build läuft mit noch ein paar zusätzlichen Optionen in der config, dauert nur alles wirklich ewig, n neuer Server (mit SSDs) wurde aber schon mit der besten Ehefrau abgesprochen für nächsten Monat.
Joa, mit Xen war ich schon immer im zu exotischen Bereich, der große Run auf die Virtualisierung hat Xen leider nicht wirklich mitgenommen. Trotzdem danke für die Hilfe bisher Ich bekomme aus dem openwrt ordner heraus mit einer entsprechenden subtarget config prima ein Image gebaut, Aber Kernel und Module rüberkopieren scheint nicht zu reichen, um das gluon-generic.img Xen-fähig zu machen
Also ich brauch die Kernel-Cracks, die mir aus meiner Openwrt .config eine config für target/x86-generic oder was auch immer machen, oder mich nochmal in die richtige Richtung treten. Ich habe schon versucht, die - meiner Meinung nach wichtigen - Werte aus der .config in die targets/x86-generic/config zu kopieren, aber leider bricht der Build dann immer beim Kernel ab und auch V=s ist da nicht wirklich aussagekräftig. Soll ich die .config auf Pastebin oder so packen? Macht das Sinn?
Könnte man ansonsten auch das Openwrt freifunk-ifizieren? Das wäre natürlich nicht updatebar usw, also wohl eher nur ein proof of concept, aber immerhin…
Am Wochenende habe ich mal den Thread „Neuanfang: VPN-Beschleunigung jeglicher Art“ und seine Vorgänger hier verfolgt und war etwas erschreckt, wie sehr dort abgedriftet wird oder wurde… Ich möchte wirklich gerne ein soweit es geht Standard-Freifunk-image haben, damit ich eben nicht irgendwann eine Uralt-Node habe, weil ich nicht selbst zum Neubauen des Images komme. Falls das hier nach der Ansicht von Leuten, die den Überblick haben, keinen Sinn macht, möge man mich einfach ignorieren, dann weiß ich Bescheid. Ohne Hilfe komme ich im Moment leider nicht weiter…
schau mal, ob Du im Gluon@hackint nachfragen möchtest.
Es würde mich freuen, wenn du da dran bleibst, da Xen bei mir nach wie vor die präferierte Virtualisierungsplatform ist.
Zumindest komme ich damit (auf headless Blechen) besser zurecht als mit KVM und Virtualbox.
Der Build läuft durch, allerdings fällt am Ende noch kein image raus und ich weiß noch nicht warum. Was ich bisher getan habe:
targets/targets.mk erweitern um diese Zeile:
$(eval $(call GluonTarget,x86,xen_domu))
unter targets/x86-xen_domu/config anlegen mit diesem Inhalt:
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_xen_domu=y
und targets/x86-xen-domu/vermagic mit jenem (daran haperte is vermutlich zu Beginn):
8e4fb34a527a3c654153a9a0eb1ebd9c
dann ein beherztes ‚make GLUON_TARGET=„x86-xen_domu“ V=s‘ und ewiges Warten. Der Build läuft ohne Fehler durch, sagt am Ende aber leider nur
make[1]: Nothing to be done for 'images'.
Trotzdem glaube ich, dass ich schon fast am Ziel bin. Heute abend mehr, wenn die Kids im Bett sind!
Es lebt!
Wobei es schon ein wenig an Frankensteins Monster erinnert, denn es wollte sich einfach kein Image bauen, also habe ich kurzerhand selbst ein LVM-Volume erstellt (ist mir eh lieber). Da rein habe ich alles aus gluon/build/x86-xen_domu/profiles/XEN/root kopiert. Dann habe ich gluon/build/x86-xen_domu/profiles/XEN/kernel/bzImage auf meine Dom0 kopiert. Folgende xmff.cfg:
und die Datei gluon/packages/gluon/libs/lua-platform-info/files/x86/xen_domu/platform_info.lua aus dem kvm_guest ordner kopiert und
Die Datei gluon/targets/x86-xen_domu/profiles.mk sieht bei mir jetzt so aus:
Aber genau da hapert es vermutlich irgendwie mit dem Image? Würde das noch funktionieren, würde ich mich ja daran versuchen das irgendwie ins Git einzuchecken, auch wenn ich sowas vor ca. 5 Jahren zuletzt mit svn gemacht habe.
Fazit: Xen-Domu läuft! Wenn auch mit viel Handarbeit. Performance werde ich hoffentlich am Wochenende mal testen können.
Super Sache, Kernel und Grub in der DomU wären in der Tat noch schöner! Die Plattform_info.lua habe ich übrigens nicht nur kopiert sondern auch noch angepasst, kann aber gerade nicht gucken wie genau, war aber recht trivial, meine ich.
local model
for line in io.lines('/proc/cpuinfo') do
model = line:match('^model name%s*:%s*(.+)$')
if model then
break
end
end
module 'platform_info'
-- The OpenWrt target
function get_target()
return 'x86'
end
-- The OpenWrt subtarget or nil
function get_subtarget()
return 'xen_domu'
end
-- The board name
function get_board_name()
return nil
end
-- The model name
function get_model()
return model
end
-- The image name for sysupgrades
function get_image_name()
return 'x86-xen'
end