x86-generic schlechte Performance unter Xen -> x86-xen_domu Image?

Hallo zusammen,
mein erster Beitrag hier, nachdem ich mich jetzt registrieren konnte! Und direkt habe ich ein Problem:

Ich möchte bei mir Zuhause Freifunk mit einer Antenne auf das Dach bringen und habe mir einen WR841DN gekauft, sowie eine bessere Antenne. Als VPN-Offloader habe ich eine VM unter XEN auf meinen eh immer laufenden Server eingerichtet mit dem Image gluon-ffkle-0.7.2+stable+ffkle+20150812-x86-generic.img.gz. Allerdings ist die Performance eher naja. Mehr als 1MBit bekomme ich gerade nicht durch und die CPU-Last auf dem Wirtsystem ist dann schon recht hoch. Liegt das an der noch neuen Aufteilung des Rheinufers oder wie ich vermute an der Hardwarevirtualisierung?

Ich hatte mich mit der „alten“ Sitelist der Domäne Rheinufer schonmal am Bauen eines Images versucht, dass die XEN-Treibermodule für Paravirtualisierung versucht, bin aber nicht so richtig zurecht gekommen, die Images enthielten am Ende trotzdem nicht die richtigen Module.
Gibt es die Möglichkeit zusätzlich zu KVM, Virtualbox und VMWare auch noch ein XEN-DomU-Image bauen zu lassen? Die automatischen Updates würden bei einem von mir gebauten Image ja nicht funktionieren. Oder kann mir jemand beim Bauen behilflich sein?

Vielen Dank im Voraus!

1 Like

Also ich denke das Problem liegt an der Virtualisierung. Ich habe da auch ziemliche Probleme mit KVM und VBox. Ich vermute, dass da was mit den Treibern noch nicht stimmt. Genaueres weiß ich leider auch nicht.

Wenn man Gluon nativ von einem Stick laufen lässt, geht da deutlich mehr. Einen genauen Vergleichstest auf derselben Hardware, damit man den Verlust Mal abschätzen kann, konnte ich leider noch nicht machen, da ich Zuhause nur VDSL25 hab.

Grüße
MPW

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.ä…

Grüße, Bench

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. :wink:

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.

Grüße
MPW

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 :wink:

EDIT: Build brach leider ab und genau da war ich auch schonmal :frowning:

...
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

Wie hast du die Module eingebaut? Neoraider hat mir gesagt, dass man niemals im OpenWRT make menuconfig rumpfuschen darf.

Lösch Mal den ganzen OpenWRT-Ordner, sodass er neu geladen wird. Der ist jetzt geschrottet.

Und dann trag die benötigten Module Mal in targets/x86-{64,generic}/profiles.mk in der ersten Zeile bei den NETWORK_MODULES ein.

/edit: Bzw. im Target für XEN, damit hab ich noch nie gearbeitet.

Grüße
MPW

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 :wink:

Das ist eigentlich der offizielle Weg Kernelmodule für bestimmte Targets zu laden. Da ist nichts geschlamptes dran.

Sorry, dann verstehe ich wohl noch weniger von dem Imagebuilder als ich dachte. Dachte neuer Einsatzzweck, neues Target, so wie beim x86-kvm_guest.

Nur die profiles.mk zu editieren reicht allerdings nicht, der Build schlägt fehl:

Collected errors:
 * opkg_install_cmd: Cannot install package kmod-xen-evtchn.
 * opkg_install_cmd: Cannot install package kmod-xen-fs.
 * opkg_install_cmd: Cannot install package kmod-xen-kbddev.
 * opkg_install_cmd: Cannot install package kmod-xen-netdev.
/mnt/tmp/gluon/Makefile:349: recipe for target 'package_install' failed

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. :wink:

Bzgl. Xen kann ich dir nicht helfen. Ich nutze nur KVM und VBox.

Grüße
MPW

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 :wink: 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 :frowning:

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. :wink: Ohne Hilfe komme ich im Moment leider nicht weiter…

Mit freundlichen Grooves, Bench

PS: Gammel auch im IRC #freifunk rum :wink:

1 Like

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.

@adorfer bin dran! Liest du da mit, oder wartest du hier, bis ich was neues vermelden kann? :wink:

1 Like

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!

1 Like

In den Kanälen lese ich nur sporadisch und das Backlog arbeite ich nicht auf. Von daher hilft die Rückmeldung hier mir weiter. Danke.

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:

kernel          = "/mnt/bzImage"
extra           = 'root=/dev/xvda1 rootfstype=ext4 rootwait xencons=hvc'
vcpus           = 1
memory          = '128'
root            = '/dev/xvda1 rw'
disk            = [ 'phy:/dev/vg1/ff-disk,xvda1,w' ]
name            = 'ff'
dhcp            = 'dhcp'
vif             = [
                'bridge=xenbr1,mac=00:16:3E:60:8F:76',
                'bridge=xenbr0,mac=00:16:3E:77:AF:D8',
                ]
on_poweroff     = 'destroy'
on_reboot       = 'restart'
on_crash        = 'destroy'

Achso, und den Beitrag hier Gluon-target Raspberry Pi und Banana Pi -brcm2708-bcm2709 / sunxi - #52 von MPW musste ich noch beachten, damit sich auch die Gluon Packages bauen und einbinden lassen. Dazu habe ich die Datei gluon/packages/gluon/libs/lua-platform-info/Makefile in Zeile 15 so angepasst:

DEPENDS:=+lua @(TARGET_ar71xx_generic||TARGET_ar71xx_nand||TARGET_mpc85xx_generic||TARGET_x86_generic||TARGET_x86_kvm_guest||TARGET_ramips_rt305x||TARGET_x86_xen_domu)

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:

FEATURES:=ext4 pci usb
$(eval $(call GluonProfile,XEN,kmod-xen-evtchn kmod-xen-fs kmod-xen-kbddev kmod-xen-netdev))
$(eval $(call GluonProfileFactorySuffix,XEN,-ext4,.img.gz))
$(eval $(call GluonProfileSysupgradeSuffix,XEN,-ext4,.img.gz))
$(eval $(call GluonModel,XEN,combined,x86-xen))

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. :wink:

Fazit: Xen-Domu läuft! Wenn auch mit viel Handarbeit. Performance werde ich hoffentlich am Wochenende mal testen können.

2 Likes

Das erstellen des Images schlägt fehlt, da es im OpenWRT-Subtarget xen_domu noch einen Bug gibt:
https://dev.openwrt.org/ticket/18074

Der sollte in zukünftigen Gluon-Versionen (mit aktuelleren OpenWRT-Versionen) behoben sein.

Ich versuche aktuell ein Xen-Image mit Grub zu bauen, damit der Linux-Kernel aus dem Image direkt mittels pygrub angesprochen werden kann.

Details reiche ich gleich nach, wenn’s fertig ist :smile:

2 Likes

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.