…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