@Parad0x hatte mich kürzlich nach Images gefragt, die virtuell auf einer Hyper-V-Umgebung laufen. Problem ist, dass spezielle Kerneltreiber erforderlich sind.
Neoraider hat mir ein paar Tipps gegeben und mir ist es gelungen die passenden Images zu bauen. Hier die Anleitung und ein paar Fotos zur Hardwarekonfiguration von @Parad0x.
(Kann ggfs. auch unter Linux durchgeführt werden.)
Hardwarekonfiguration passend einstellen. Wie auch bei anderen virtuellen Images ist die zweite Netzwerkkarte (eth1) der Uplinkport (bei den Hardwareroutern der blaue).
Die interne Netzwerkkarte (= eth0 = Erste im Hyper-V) muss in den Erweiterten Features der Netzwerkkarte in den Hyper-V-Einstellungen noch das MAC-Spoofing aktiviert bekommen.
Der Patch ist in LEDE vorhanden, mit Gluon 2017.1.x kann das x86-64 Image konvertiert und genutzt werden. Es sind sogar Integrationskomponenten vorhanden, dies ermöglicht ein Shutdown der VM von außen über die Konsole (oder bei einem Neustart des Server).
Der RAM der VM konnte in Tests auf 128 MB reduziert werden, mit 64 MB kann das System nicht vollständig starten und hängt in einem Bootloop.
Dies ist ein Wiki, falls sich mal was ändert, gerne anpassen.
Du kannst bei Hyper-V ab Windows Server 2012 R2 zwei verschiedene VM-Typen anlegen. Die von dir gezeigte Konfiguration zeigt eine Generation 1-VM, die basiert auf einem BIOS, kann emulierte Geräte wie das Diskettenlaufwerk usw… Generation 2 basiert auf UEFI, da kann es sein dass Gluon auf dieser Basis nicht läuft.
Gruß, Jan
Neu ist die Erkenntnis, dass das interne Netzwerk die Hyper-V-Option „MAC spoofing aktivieren“ gesetzt haben muss. Das interne Port nutzt bei Gluon nicht das Hardware Interface (=Hyper-V-Interface)
Eine ähnliche Option muss auch bei anderen Hypervisorn gesetzt werden,
Neu? Bist Du Dir da sicher?
Diese Notwendigkeit betrifft alle Systeme, die ihren Gast-NICs Vorschriften bezüglich der genutzten MACs machen (per default, oder weil es jemand so aus $GRUENDEN konfiguriert hat.)
Nein, ich glaube nicht.
Ich habe das Virtualbox Image genommen und konvertiert (Dazu benötigt man aber kurz Virtualbox). MAC Spoofing nicht vergessen. Mehr habe ich nicht gemacht, dauert nicht lange.
Allerdings habe ich Performance-Probleme und ich weiß nicht woran es liegt (Habe aber auch noch nicht weiter geschaut). Mein Hyper-V Offloader ist genauso schnell wie ein 1043 V4. Allerdings ist mein hyper-V Server auch nicht sonderlich gut ausgestattet, alter Xeon…
Ich hatte ein X86-Image vormals mal auf einem ESXI und das lief nicht langsamer als jetzt per KVM unter Proxmox.
Und der Prozessor war auch eher unterdurchschnittlich (6 Jahre alter i7…)
Vermutlich eher ein Finetuning-Problem, z.B. mit den Laninterfaces. (Und auch mit der Anspruchshaltung. Ich vermag nicht einzuschätzen, was Du als „Problem“ ansiehst. Ein 1043v3 schafft bei mir rund 90MBit/s „Per Speedtest“ Schneller wird’s auch mit dem Offloader nicht.)
Naja, mit fastd schafft ein 1043er bei uns nur 10-12 Mbit… Und leider meine VM auch nicht mehr… Ein WRT1200AC schafft da bei mir >55 Mbit (noch nicht am Kabel getestet, aber sicher noch darüber)
Ich hab mal die Infos oben ergänzt zum Thema Lede, hab noch nen Screenshot erstellt wegen dem MAC Spoofing und habe das mal getestet. „Ganz gut“ sag ich mal
Es gibt keinen Bedarf für die Legacy-Netzwerkkarte. Seit dem Schwenk auf LEDE funktioniert Gluon auch mit der „normalen“ Netzwerkkarte, sichtbar oben in meinem Screenshot und auch technisch sichtbar durch die mehr als 100 MBit beim Speedtest. Außerdem erhöht die Legacy-Karte die Last auf dem Mgmt-OS, da hier die beiden emulierten Karten gerechnet werden.
Gruß, Jan
Ich sehe nicht, dass sich binnen der letzten Jahre (auch von Gluon 2015 zu Gluon 2016) etwas geändert hätte.
Es gibt halt jetzt nur auch x64-images, aber was die Treiberebene anbelangt und den untertützten paravirt-Netzwerkkarten ist das sehr stabil seit 2015.2(?).
Daher verstehe ich wirklich nicht so ganz, worüber hier jetzt eigentlich EXAKT diskutiert wird.
