Offloader in VMware/QEMU/Virtualbox

Technik Gluon
1

Bei mir zu Hause habe ich einen Linux-Server dauerhaft laufen und war von der Fastd-Performance der 841er ziemlich enttäuscht. Daher habe ich schon lange mit dem Gedanken gespielt, einen virtuellen Offloader laufen zu lassen, und die 841er alle per Mesh-on-LAN über VLAN zu betreiben. In diesem Thread will ich kurz meine bisherigen Erfahrungen dazu dokumentieren.

Generell gilt scheinbar: die erste Netzwerkkarte ist für Freifunk-LAN/Mesh/etc, die zweite Netzwerkkarte für den Uplink. Das kann schonmal einen ziemlichen Knoten ins Gehirn machen, wenn eth0 im Host eben nicht eth0 im Gast ist. Denn normalerweise will man ja sein eth0 des physikalischen Hosts mit dem Uplink des virtuellen Gasts verbinden.

  • VMware

Da ich beruflich immer mit VMware Workstation arbeite, habe ich zuerst versucht, einen Offloader als VMware Image zu erzeugen. Sollte ja theoretisch einfach sein, neue virtuelle Maschine erstellen, vmdk-Datei als Festplatte benutzen und los gehts.

Leider blieb die Firmware immer mit “Switched to clocksource tsc” stehen.

Ich habe dann unterschiedliche VMware-HW-Compatibility Levels probiert (6 und 12), habe das VMDK konvertieren lassen (schlägt VMware beim importieren vor) oder es nicht konvertiert, immer dasselbe Ergebnis. Failsafe konnte ich im Grub-Menü auswählen, ändert aber auch nichts.

Nach einiger Suche im Internet hatte ich dann die Idee, mal die virtuelle Festplatte als IDE und nicht als SCSI einzubinden, und dann hat es auf Anhieb funktioniert.

Da es aber dann so aussah, als wenn VMware Player mittlerweile etwas kosten würde, habe ich das dann bleiben lassen (mittlerweile weiß ich, dass man den Player privat kostenlos nutzen darf). Da das mit den Updates aber auch nicht so der Knaller ist, kam dann der nächste Versuch.

  • QEMU

Sollte prinzipiell auch einfach sein, aber das Verbinden der Netzwerkinterfaces ist einfach unendlich kompliziert gelöst. Daher habe ich QEMU nicht wirklich weiter getestet, nachdem ich schon beim Netzwerk gescheitert bin.

  • Virtualbox

Habe ich bisher nie benutzt, hat mich aber positiv überrascht und ich benutze es jetzt auch für meinen Offloader. Hier war der einzige Stolperstein der, dass man bei der Netzwerkkarte explizit den “Promiscuous Mode” erlauben muss, sonst kommen die DHCP-Antworten irgendwie nicht durch.

6 „Gefällt mir“
2

Mittlerweile bin ich etwas weiter gekommen… VLAN-Einstellungen am Switch (mit etwas Kopfkratzen) hinbekommen, Offloader nochmal komplett aufgesetzt (scheinbar Disk-Image korrupt, bei uci commit kam immer “IO Error”).

Mittlerweile meshen scheinbar Bensheim-002 und -006 mit Bensheim-002-Offloader, und ich kommen auch ins Internet. Allerdings sind laut Karte Bensheim-002 und -006 offline und der Offloader mesht garnicht. Kann das jemand erklären?

http://[2a01:4f8:100:57ff:a00:27ff:fe0c:c319]/

@leah: Kannst Du den ersten Knoten, der Bensheim-002-Offloader heißt irgendwie löschen? Ich habe mit demselben Token einen Offloader mit demselben Namen erzeugt, aber die MAC war anders. Dadurch ist irgendwas in der Datenbank durcheinandergekommen… Ist das auch der Grund für die Fehler in der Karte?

3

Nein.

Eigentlich nicht. Du kannst da auch die MAC zu einem Namen ändern. Ist vollkommen in Ordnung.

4

Ich hatte mit dem Token die MAC geändert, und anschließen waren 2 Knoten mit demselben Namen in der Map drin. Das hat sich aber scheinbar von selbst repariert.

Aber das Problem ist immer noch da:

Bensheim-002 und Bensheim-006 werden in der Map als Offline angezeigt, und beim Offloader werden in der Karte keine Nachbarknoten angezeigt. Wenn man direkt auf die Webseite des Offloaders geht, sieht man jedoch, wie er mit Bensheim-002 und -006 meshed, und ich komme ja auch darüber problemlos ins Netz:

http://[2a01:4f8:100:57ff:a00:27ff:fe0c:c319]/

Kommen vielleicht die Alfred-Infos nicht richtig durch meine VLANs durch? Wobei zumindest der Offloader ja der Karte sagen können müsste, dass mit den beiden Knoten meshed.

5

Noch ein Phänomen auf dem Offloader:

root@leahsheim-002-Offloader:~# opkg update
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/base/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_base.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/base/Packages.sig.
Signature check passed.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/packages/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_packages.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/packages/Packages.sig.
Signature check passed.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/luci/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_luci.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/luci/Packages.sig.
Signature check passed.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/routing/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_routing.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/routing/Packages.sig.
Signature check passed.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/telephony/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_telephony.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/telephony/Packages.sig.
Signature check passed.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/management/Packages.gz.
Updated list of available packages in /var/opkg-lists/chaos_calmer_management.
Downloading http://opkg.mirror.ffrn.de/openwrt/chaos_calmer/15.05.1/x86/generic/packages/management/Packages.sig.
Signature check passed.
Downloading http://opkg.mirror.ffrn.de/modules/gluon-ffrn-0.6.1-20160922/x86/generic/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Downloading http://opkg.mirror.ffrn.de/modules/gluon-ffrn-0.6.1-20160922/x86/generic/Packages.sig.
wget: server returned error: HTTP/1.1 404 Not Found
Signature check failed.
Remove wrong Signature file.
Collected errors:
 * opkg_download: Failed to download http://opkg.mirror.ffrn.de/modules/gluon-ffrn-0.6.1-20160922/x86/generic/Packages.gz, wget returned 1.
 * opkg_download: Failed to download http://opkg.mirror.ffrn.de/modules/gluon-ffrn-0.6.1-20160922/x86/generic/Packages.sig, wget returned 1.
root@leahsheim-002-Offloader:~#

Kann das jemand erklären? Oder ist das nicht so schlimm?

6

Habe das Problem, dass die Mesh-on-LAN-Knoten nicht in der Karte angezeigt werden, einkreisen können. Alfred wird nicht korrekt gestartet, oder beendet sich irgendwie von selbst. Wenn ich alfred manuell starte, sind die Knoten auf der Karte und im Grafana sichtbar.

Hier ein logread von einem betroffenen Knoten:

https://paste.ffrn.de/?6b7c2577a9ce4bd2#dRdNsIwSQQtY3w2NlZuuy/lmIl4Gbq2xjjpoyemscdM=

7

…und wieder etwas schlauer geworden.

Die Performance ließ etwas zu wünschen übrig, daher habe ich mit folgendem Script mal die fastd-performance getestet:

Nativ: 207 Mbits/sec
Virtualbox: 48.6 Mbits/sec
(Prozessor N3150)

Also wollte ich statt Virtualbox doch nochmal VMware ausprobieren, das hat angeblich weniger Virtualisierungsoverhead. Da habe ich aber den Offloader wiederum nicht richtig zum laufen bekommen. Ich habe jetzt mit Wireshark etwas rumdebugged, und folgendes herausgefunden:

Das WAN-Interface hat eine die vom VMware-Vergebene MAC, und die sieht man auch bei eth1. Die DHCP-Requests schickt der Offloader aber mit der MAC von br-wan, und das ist eine ganz andere MAC. Bei Virtualbox gab es dafür extra Einstellungen (Promiscuous mode), bei VMware habe ich nichts dazu gefunden.

Mittlerweile habe ich diesen Bug-Report gefunden:

Der aktuelle Stand von gluon auf virtueller Hardware ist aktuell eher alpha als beta, geschweige denn stabil.

An dieser Stelle habe ich dann mehr oder weniger aufgegeben. Mit viel Aufwand habe ich noch einen Performancevergleich von VMware Workstation machen können, mit folgendem Ergebnis:

Nativ: 753 Mbits/sec
VMware: 384 MBits/sec
(Prozessor i7-3770)

Zusammengefasst:

  • Gluon läuft auf Virtuelle Maschinen nicht gescheit (Gluon ist Schuld)
  • fastd schafft in Virtualbox ca. 25% der Hostgeschwindigkeit
  • fastd schafft in VMware Workstation 12 ca. 50% der Hostgeschwindigkeit

Desweiteren sollten wir überlegen, auf der Firmware-Seite die Links zu dem virtuellen Disks bei den Offloader Images rauszunehmen, weil die praktisch unbenutzbar sind (und mich diese Erkenntnis viele Stunden gekostet hat).

@leah: Den Knoten Offloader-Experiment-Temp kannst Du löschen (oder kann man das mittlerweile selbst?). Außerdem liefert Grafana zum Namen „Bensheim-002-Offloader“ immer 2 Hosts, kannst Du davon den inaktiven löschen? Beispiel:

http://s.ffrn.de/dashboard/db/nodes?panelId=4&fullscreen&var-Node=Bensheim-002-Offloader

2 „Gefällt mir“
8

Ich finde es gut, dass die Images verfügbar sind. Selbst wenn die Performance zu Wünschen übrig lässt und die Installation „etwas anspruchsvoller“ ist. Zum Spielen, Lernen und Debuggen scheint es ja auszureichen.

Vielleicht kannst Du die nötigen Schritte und Anpassungen mal in einem Wiki-Artikel zusammenfassen?

9

Vielleicht nur in der Experimental-Sektion drin lassen, und bei Stable raus?

Wie gesagt, mit VMware Workstation habe ich es garnicht zum Laufen bekommen, für ESXi stehen die meisten Kniffe in dem Bugreport. QEMU habe ich bleiben lassen.

Für Virtualbox könnte ich einen Artikel schreiben, das stimmt. Aber die Performance ist so schlecht, dass es meiner Meinung nach wenig Sinn macht (außer man hat einen relativ schnellen Rechner, dann kann man vielleicht auf 100MBit kommen.

Wobei ich diesem Post wenig hinzuzufügen hätte:

10

Performance ist immer relativ. Ich finde die von Dir gemessenen 48 MBit/s gar nicht so schlecht - die muss der Internetanschluss erst mal hergeben.

Ich würde auch keine VM wegen der Performance nehmen. Mir ginge es eher um Snapshots, Paralleler Betrieb mehrerer Instanzen, Traffic-Monitoring, …

Die Unterscheidung stable/beta/experimental bezieht sich auf die Gluon-Version. Aber man könnte einen separate Zeile “x86-experimental” einführen, die dann pro Gluon-Version existiert.

11

Ich habe bei mir ein Karlsruher Image in KVM laufen. Das war eigentlich ohne Probleme. Durchsatz war auch so 50 Mbit, Core I3. Allerdings Server in Kanada, hab nie wirklich getestet was von der Maschine her überhaupt möglich wäre. Einen Switch zu haben an den man mal schnell einen Client testen kann und IPv6 hat war mir genug :)

12

Ich habe zwischenzeitlich eine andere Maschine genommen und nachdem mein privater Kram dort drauf lief auch das Image von FFRN getestet.
Die Maschine läuft unter proxmox und damit KVM.

Schritte:
wget "https://fw.ffrn.de/stable/factory/gluon-ffrn-0.5.13-20160919-x86-generic.img.gz" gzip -d gluon-ffrn-0.5.13-20160919-x86-generic.img.gz qemu-img convert -f raw gluon-ffrn-0.5.13-20160919-x86-generic.img -O qcow2 gluon-ffrn.qcow cp gluon-ffrn.qcow /var/lib/vz/images/102/vm-102-disk-1.qcow2
Als Netzwerk habe ich zwei e1000-Karten genommen. Als Client dient eine weitere VM, die ein kleines Debian drauf hat.
Ich habe ein paar Downloads mit wget gemacht, die lagen dann bei ca 35 MBit. Nicht schnell, aber läuft. Der Wirt hat auch nur eine 100er Anbindung, CPU: AMD Athlon™ II X4 605e Processor

13

Ein Beitrag wurde in ein neues Thema verschoben: Freifunk Offloader via KVM/Proxmox