4
WiFi-Bridge auf Host mit VM bei anmeldegebundenen DHCP-Leases (Geräte-MAC)
Hallochen, Gemeinde!
Ich hoffe, dass werden nicht meine 5 Cent für den Freitagnachmittag ...
Das ursprüngliche Problem bestand darin, dass bei einem Linux-Host (Notebook mit Debian 11) mit Windows-QEMU-VM die VM keinen Außenkontakt herstellen konnte, wenn der Host über den WLAN-Adapter mit einem Netzwerk verbunden ist. Problematisch war das deshalb, weil der WLAN-Adapter bisher scheinbar die WDS-Funktionalität nicht bereitstellen konnte, was zu den entsprechenden Folgewirkungen führte. Jedenfalls beherrscht der WLAN-Adapter WDS/4addr und es kann aktiviert werden. Somit verhält sich jetzt der WLAN-Adapter identisch mit dem LAN-Adapter, was die Konnektivität der QEMU-VM betrifft.
So weit, so gut. ABER und das ist die neue Problematik:
Bei einer LAN-Anbindung ist es mit dem lokalen Bridging des Hosts selbstredend, dass sich der Host und die VM ihre (dynamische oder statische) IP-Konfiguration per DHCP holen. Das erfordert einen entsprechenden DHCP-Server im LAN. Dasselbe gilt für eine Anbindung von Host und VM in ein WiFi-Netzwerk, weil der Host selbst nicht an der Vergabe der IP-Daten beteiligt ist (und insoweit auch nicht soll).
Indes entsteht daraus bei einer WiFi-Anbindung eine Folgeproblematik, wenn der Access Point die DHCP-Leases (nur) anhand der MAC-Adresse des WLAN-Adapters des sich anmeldenden Gerätes vergibt oder die Kommunikation auf die bei der Geräteanmeldung registrierten MAC-Adresse beschränkt. Ist das Gerät allein, ist das auch völlig in Ordnung. In der Konstallation des Bridgings auf dem Host ist das kritisch, weil es dann drei MAC-Adressen gibt, die versorgt werden müssen. Bei einer brctl- oder OVS-Bridge haben nämlich neben dem WLAN-Adapter sowohl das Interface der Bridge als auch die VM ihre eigene MAC-Adresse und benötigen somit jeweils eine IP-Zuordnung.
Ein umgehender/vermeidender Lösungsansatz ist, einen per LAN-Kabel an den Host angeschlossenen mobilen Router zu verwenden. Nur wird dieser nicht immer zugegen sein und / oder es soll auch ohne ihn gehen können.
Was ist dann zu tun? Einfach manuell eine IP-Adresse zu vergeben, mag klappen können. Dürfte aber wegen der fehlenden Registrierung der IP-Adresse im AP-Netz schon an der Ablehnung durch den AP scheitern. Ein denkbares Beispiel wäre ein (noch) kleiner(er) mobiler, aber einfacher WiFi-ComPoint.
1. Gibt es neben den beiden nachstehenden noch andere vernünftige Lösungsansätze?
2. Wie könnte ein virtueller Router realisiert werden, ohne großen Aufwand zu treiben? Kann das in Open vSwitch integriert werden? Boardmittel? Wie würde eine entsprechende Konfiguration aussehen? Oder muss es so etwas wie OpenWRT etc. sein?
3. Wie sähe das bei einer Tunnellösung (VPN oder dergleichen) aus? Der Tunnel erhält doch regelmäßig eine virtuelle Schnittstelle, die dann anstelle des WLAN-Adapters in die Bridge eingebunden werden könnte, oder? Freilich bedarf es dann einer entsprechenden Tunnelgegenstelle. Und klar ist auch, dass die anderen internen Interfaces (von Host und VM) durch den Host mit IP-Adressen versorgt werden müssen. Ein Vorteil könnte sein, dass sich die VPN-Anbindung der VM / des Hosts zu einer gemeinsamen (transparenten) für Host und VM verlangern würde und dass dadurch kein nennenswerter zusätzlicher Aufwand entstehen würde.
Wichtig ist mir, dass zwischen den verschiedenen WiFi-Szenarien möglichst einfach gewechselt werden kann, und zwar ähnlich wie zwischen LAN-Anbindung und WiFi-Anbindung (Austausch der Interfaces in der Bridge).
Im Voraus vielen Dank für Euren Input und viele Grüße
HansDampf06
Ich hoffe, dass werden nicht meine 5 Cent für den Freitagnachmittag ...
Das ursprüngliche Problem bestand darin, dass bei einem Linux-Host (Notebook mit Debian 11) mit Windows-QEMU-VM die VM keinen Außenkontakt herstellen konnte, wenn der Host über den WLAN-Adapter mit einem Netzwerk verbunden ist. Problematisch war das deshalb, weil der WLAN-Adapter bisher scheinbar die WDS-Funktionalität nicht bereitstellen konnte, was zu den entsprechenden Folgewirkungen führte. Jedenfalls beherrscht der WLAN-Adapter WDS/4addr und es kann aktiviert werden. Somit verhält sich jetzt der WLAN-Adapter identisch mit dem LAN-Adapter, was die Konnektivität der QEMU-VM betrifft.
So weit, so gut. ABER und das ist die neue Problematik:
Bei einer LAN-Anbindung ist es mit dem lokalen Bridging des Hosts selbstredend, dass sich der Host und die VM ihre (dynamische oder statische) IP-Konfiguration per DHCP holen. Das erfordert einen entsprechenden DHCP-Server im LAN. Dasselbe gilt für eine Anbindung von Host und VM in ein WiFi-Netzwerk, weil der Host selbst nicht an der Vergabe der IP-Daten beteiligt ist (und insoweit auch nicht soll).
Indes entsteht daraus bei einer WiFi-Anbindung eine Folgeproblematik, wenn der Access Point die DHCP-Leases (nur) anhand der MAC-Adresse des WLAN-Adapters des sich anmeldenden Gerätes vergibt oder die Kommunikation auf die bei der Geräteanmeldung registrierten MAC-Adresse beschränkt. Ist das Gerät allein, ist das auch völlig in Ordnung. In der Konstallation des Bridgings auf dem Host ist das kritisch, weil es dann drei MAC-Adressen gibt, die versorgt werden müssen. Bei einer brctl- oder OVS-Bridge haben nämlich neben dem WLAN-Adapter sowohl das Interface der Bridge als auch die VM ihre eigene MAC-Adresse und benötigen somit jeweils eine IP-Zuordnung.
Ein umgehender/vermeidender Lösungsansatz ist, einen per LAN-Kabel an den Host angeschlossenen mobilen Router zu verwenden. Nur wird dieser nicht immer zugegen sein und / oder es soll auch ohne ihn gehen können.
Was ist dann zu tun? Einfach manuell eine IP-Adresse zu vergeben, mag klappen können. Dürfte aber wegen der fehlenden Registrierung der IP-Adresse im AP-Netz schon an der Ablehnung durch den AP scheitern. Ein denkbares Beispiel wäre ein (noch) kleiner(er) mobiler, aber einfacher WiFi-ComPoint.
1. Gibt es neben den beiden nachstehenden noch andere vernünftige Lösungsansätze?
2. Wie könnte ein virtueller Router realisiert werden, ohne großen Aufwand zu treiben? Kann das in Open vSwitch integriert werden? Boardmittel? Wie würde eine entsprechende Konfiguration aussehen? Oder muss es so etwas wie OpenWRT etc. sein?
3. Wie sähe das bei einer Tunnellösung (VPN oder dergleichen) aus? Der Tunnel erhält doch regelmäßig eine virtuelle Schnittstelle, die dann anstelle des WLAN-Adapters in die Bridge eingebunden werden könnte, oder? Freilich bedarf es dann einer entsprechenden Tunnelgegenstelle. Und klar ist auch, dass die anderen internen Interfaces (von Host und VM) durch den Host mit IP-Adressen versorgt werden müssen. Ein Vorteil könnte sein, dass sich die VPN-Anbindung der VM / des Hosts zu einer gemeinsamen (transparenten) für Host und VM verlangern würde und dass dadurch kein nennenswerter zusätzlicher Aufwand entstehen würde.
Wichtig ist mir, dass zwischen den verschiedenen WiFi-Szenarien möglichst einfach gewechselt werden kann, und zwar ähnlich wie zwischen LAN-Anbindung und WiFi-Anbindung (Austausch der Interfaces in der Bridge).
Im Voraus vielen Dank für Euren Input und viele Grüße
HansDampf06
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2770635769
Url: https://administrator.de/contentid/2770635769
Printed on: April 24, 2024 at 07:04 o'clock
4 Comments
Latest comment
Bei einer brctl- oder OVS-Bridge haben nämlich neben dem WLAN-Adapter sowohl das Interface der Bridge als auch die VM ihre eigene MAC-Adresse
Nach Adam Riese wären das 2! Wieso kommst du auf 3?Abgesehen von der Mathematik ist es doch Unsinn der Bridge selber ein Interface zu geben. Die soll doch nur passiv durchreichen. Und wenn überhaupt, dann hat sie einzig nur eine Adresse aus dem LAN Netz sofern das überhaupt erforderlich ist bei einem Bridge. Generell sollten immer nur die Endgeräte selber eine IP Adresse haben.
Aber auch wenn, ist ja für die Mac basierte IP Adressvergabe auf dem AP einzig und allein nur die Mac Adresse der VM relevant, denn mit dieser werden ja die DHCP Requests versendet. Die Bridge selber wird ja sehr wahrschenlich keine DHCP Requests senden, wozu auch? Aber auch wenn, ist die Mac dazu dann irrelevant, denn es muss ja nur die VM selber eine IP haben um zu funktionieren. Die Bridgefunktion an sich ist ja keinesfalls abhängig von einer IP Adresse. Eine Bridge arbeitet rein nur auf Layer 2, für die sind IP Adressen so oder generell irrelevant.
Eintragen im AP oder dem WLAN DHCP Server muss man also nur die VM Mac Adresse.
Mit einem tcpdump sieht man das auch selber.
Beachte zudem auch das wenn LAN und WLAN gleichzeitg aktiv sind das für Windows problematisch ist, da es nicht mit 2 aktiven Gateway und DNS Adressen umgehen kann. Bzw. hier immer nur die Bindungsreihenfolge der NIC Adapter (Metric) dann zählt welcher Adapter überhaupt aktiv ist. Nur das du das auch auf dem Radar hast...
@aqui: Zunächst besten Dank für Deinen Kommentar.
Leider ist das kein Unsinn, weil bei einer OVS-Bridge bei deren Erstellung das zugleich erstellte Interface denselben Namen wie die Bridge hat und als interner Typ markiert ist. Erst danach können das (W)LAN-Interface und das VM-Interface hinzugefügt werden. Über sein Interface steuert OVS die Bridge = local port der Bridge (siehe die Fehlermeldung bei einem Löschversuch über ovs-vsctl del-port). Ich würde mit meinem einfachen Verständnis sagen: by design / as designed.
Überdies ist das Beseitigen/Nichtvergeben einer IP-Adresse für das Bridge-Interface möglich, aber realiter sinnlos. Denn dann kann der Host nicht mehr mit seiner Umwelt kommunizieren und irgendetwas passiv durchreichen will er dann auch nicht. Entscheidend ist einzig und allein der Routingeintrag für das Bridge-Interface; dann funktioniert alles andere, was an der Bridge hängt. Eine IP-Adresse wird für den (W)LAN-Adapter lediglich benötigt, um das Bridge-Interface seine IP-Adresse per DHCP abrufen zu lassen. Danach können die Routingeinträge des (W)LAN-Adapters gelöscht (oder in der Metric zurückgesetzt) werden. Das kann endlos reproduziert werden.
Aber das gilt nicht nur für die OVS-Bridge, sondern nicht viel anders ebenso für die brctl-Bridge. Jedenfalls auf meinem Debian 11 ist das nach der bisherigen Erfahrung so ...
Um nichts anderes geht's für den Host, die VM und (ferner) das erfolgreiche Bridging (s.o.): Die Versorgung mit den erforderlichen IP-Adressen für das betreffende (fremde) Netzwerk.
Aus der Sicht der VM ist das zweifelsohne richtig. Und aus der Sicht des AP, wenn er DHCP-Requests nur bezogen auf die MAC-Adresse beantwortet, die bei der Herstellung der WiFi-Verbindung verwendet wurde? Das ist doch DAS PROBLEM, um was es mir geht!
Siehe oben.
Darum geht es hier doch gar nicht. VIELMEHR: Der DHCP-Request der VM wird von der Bridge - dank WDS - schlicht durchgereicht und erhält VOM AP NICHT die gewünschte Antwort, WEIL DER AP bei der Behandlung von DHCP-Requests EINE BESCHRÄNKUNG aufweist.
Deine Ausführungen, @aqui, stellen wohl eher darauf ab, dass es diese Beschränkungen nicht gibt (z.B. separater DHCP-Server hinter dem AP) und dann passt ja auch alles. Dann stellt sich die (an die Geräte-MAC gebundene) WiFi-Verbindung als ein bloßes Transportmedium dar und Host / VM bekommen fein säuberlich ihre eigenen IP-Adressen per DHCP.
Mir scheint, dass Du eher den Fall vor den Augen hast, dass der WLAN-Adapter kein WDS/4addr kann und daher PROXY ARP (nebst DHCP-Helfer) oder so verwendet werden muss. Jedoch ist das bei vorhandener WDS-Funktionalität entbehrlich.
Das ist mir bekannt. Es gilt nicht nur bei Windows, sondern auch für - jedenfalls mein - Debian. Die gleichzeitige Einbindung des LAN- und des WLAN-Adapters war bisher nicht zielführend, so dass ich derzeit bei einem Netzwechsel als sicheren Weg die Adapter in der Bridge austausche. Freilich kann ich in der Zukunft nach einer Lösung schauen. Indes ist das derzeit zweitrangig ...
Bei der Lösung meines hier angesprochenen Problems hilft das alles leider nicht wirklich weiter.
Hat jemand Anregungen oder Hinweise zu den drei von mir im Eröffnungsbeitrag genannten Lösungsansätzen?
Viele Grüße
HansDampf06
... ist es doch Unsinn der Bridge selber ein Interface zu geben. Die soll doch nur passiv durchreichen.
Leider ist das kein Unsinn, weil bei einer OVS-Bridge bei deren Erstellung das zugleich erstellte Interface denselben Namen wie die Bridge hat und als interner Typ markiert ist. Erst danach können das (W)LAN-Interface und das VM-Interface hinzugefügt werden. Über sein Interface steuert OVS die Bridge = local port der Bridge (siehe die Fehlermeldung bei einem Löschversuch über ovs-vsctl del-port). Ich würde mit meinem einfachen Verständnis sagen: by design / as designed.
Überdies ist das Beseitigen/Nichtvergeben einer IP-Adresse für das Bridge-Interface möglich, aber realiter sinnlos. Denn dann kann der Host nicht mehr mit seiner Umwelt kommunizieren und irgendetwas passiv durchreichen will er dann auch nicht. Entscheidend ist einzig und allein der Routingeintrag für das Bridge-Interface; dann funktioniert alles andere, was an der Bridge hängt. Eine IP-Adresse wird für den (W)LAN-Adapter lediglich benötigt, um das Bridge-Interface seine IP-Adresse per DHCP abrufen zu lassen. Danach können die Routingeinträge des (W)LAN-Adapters gelöscht (oder in der Metric zurückgesetzt) werden. Das kann endlos reproduziert werden.
Aber das gilt nicht nur für die OVS-Bridge, sondern nicht viel anders ebenso für die brctl-Bridge. Jedenfalls auf meinem Debian 11 ist das nach der bisherigen Erfahrung so ...
Und wenn überhaupt, dann hat sie einzig nur eine Adresse aus dem LAN Netz sofern das überhaupt erforderlich ist bei einem Bridge. Generell sollten immer nur die Endgeräte selber eine IP Adresse haben.
Um nichts anderes geht's für den Host, die VM und (ferner) das erfolgreiche Bridging (s.o.): Die Versorgung mit den erforderlichen IP-Adressen für das betreffende (fremde) Netzwerk.
Aber auch wenn, ist ja für die Mac basierte IP Adressvergabe auf dem AP einzig und allein nur die Mac Adresse der VM relevant, denn mit dieser werden ja die DHCP Requests versendet.
Aus der Sicht der VM ist das zweifelsohne richtig. Und aus der Sicht des AP, wenn er DHCP-Requests nur bezogen auf die MAC-Adresse beantwortet, die bei der Herstellung der WiFi-Verbindung verwendet wurde? Das ist doch DAS PROBLEM, um was es mir geht!
Die Bridge selber wird ja sehr wahrschenlich keine DHCP Requests senden, wozu auch? Aber auch wenn, ist die Mac dazu dann irrelevant, denn es muss ja nur die VM selber eine IP haben um zu funktionieren. Die Bridgefunktion an sich ist ja keinesfalls abhängig von einer IP Adresse.
Siehe oben.
Eine Bridge arbeitet rein nur auf Layer 2, für die sind IP Adressen so oder generell irrelevant. Eintragen im AP oder dem WLAN DHCP Server muss man also nur die VM Mac Adresse.
Mit einem tcpdump sieht man das auch selber.
Mit einem tcpdump sieht man das auch selber.
Darum geht es hier doch gar nicht. VIELMEHR: Der DHCP-Request der VM wird von der Bridge - dank WDS - schlicht durchgereicht und erhält VOM AP NICHT die gewünschte Antwort, WEIL DER AP bei der Behandlung von DHCP-Requests EINE BESCHRÄNKUNG aufweist.
Deine Ausführungen, @aqui, stellen wohl eher darauf ab, dass es diese Beschränkungen nicht gibt (z.B. separater DHCP-Server hinter dem AP) und dann passt ja auch alles. Dann stellt sich die (an die Geräte-MAC gebundene) WiFi-Verbindung als ein bloßes Transportmedium dar und Host / VM bekommen fein säuberlich ihre eigenen IP-Adressen per DHCP.
Mir scheint, dass Du eher den Fall vor den Augen hast, dass der WLAN-Adapter kein WDS/4addr kann und daher PROXY ARP (nebst DHCP-Helfer) oder so verwendet werden muss. Jedoch ist das bei vorhandener WDS-Funktionalität entbehrlich.
Beachte zudem auch das wenn LAN und WLAN gleichzeitig aktiv sind das für Windows problematisch ist, da es nicht mit 2 aktiven Gateway und DNS Adressen umgehen kann. Bzw. hier immer nur die Bindungsreihenfolge der NIC Adapter (Metric) dann zählt welcher Adapter überhaupt aktiv ist. Nur das du das auch auf dem Radar hast...
Das ist mir bekannt. Es gilt nicht nur bei Windows, sondern auch für - jedenfalls mein - Debian. Die gleichzeitige Einbindung des LAN- und des WLAN-Adapters war bisher nicht zielführend, so dass ich derzeit bei einem Netzwechsel als sicheren Weg die Adapter in der Bridge austausche. Freilich kann ich in der Zukunft nach einer Lösung schauen. Indes ist das derzeit zweitrangig ...
Bei der Lösung meines hier angesprochenen Problems hilft das alles leider nicht wirklich weiter.
Hat jemand Anregungen oder Hinweise zu den drei von mir im Eröffnungsbeitrag genannten Lösungsansätzen?
Viele Grüße
HansDampf06
Sorry, aber bei solchen einem gruseligen Hypervisor der einem solche eigentlich völlig unsinnigen Hürden in den Weg stellt solltest du vielleicht generell einmal überdenken ob der die richtige Wahl ist. Du wirst das unter den Voraussetzungen dann nur mit 2 Mac Adressen im DHCP lösen können. Wie auch sonst wenn das strikte Vorgabe ist?!
Aber vielleicht wissen dann andere Forenprofis da mehr...
Nebenbei:
Eine einfache und simple VirtualBox benötigt auch unter Linux keinerlei IP Adressen für interne vSwitches oder Bridges und würde deine Vorgabe im Handumdrehen mit nur einer Mac lösen. Keiner der gängigen Hypervisoren benötigt IPs für Bridges.
Mit einer VirtualBox würdest du also in jedem Falle allemal besser fahren, denn diese benötigt, wie es sein soll, nur eine Mac Adresse der VM. Die VM kann dann flexibel in jedes beliebige WLAN, egal welche SSID und Authentisierungsverfahren, wechseln.
Aber vielleicht wissen dann andere Forenprofis da mehr...
Nebenbei:
Eine einfache und simple VirtualBox benötigt auch unter Linux keinerlei IP Adressen für interne vSwitches oder Bridges und würde deine Vorgabe im Handumdrehen mit nur einer Mac lösen. Keiner der gängigen Hypervisoren benötigt IPs für Bridges.
Mit einer VirtualBox würdest du also in jedem Falle allemal besser fahren, denn diese benötigt, wie es sein soll, nur eine Mac Adresse der VM. Die VM kann dann flexibel in jedes beliebige WLAN, egal welche SSID und Authentisierungsverfahren, wechseln.
@aqui: Ich verstehe Deine Reaktion(en) ganz einfach nicht.
Du "beschimpfst" die originäre Kernel-Implementierung aller aktuellen Linux-Varianten: KVM. Alle namhaften Hypervisoren auf Linux-Basis nutzen das nebst Teilen von QEMU unter der Haube - KVM(/QEMU) ist so zu sagen die native(ste) VM-Unterstützung. Und das soll wirklich ein gruseliger Hypervisor sein? Die anderen sind doch - zugespitzt ausgedrückt - nur eine Shell um KVM ...
Freilich kann ein FETTER Xen Hypervisor verwendet werden, der - windowsgleich - das schlanke Debian aufbläst ... Dennoch ist QEMU aufgrund seiner zentralen Stellung in diesem Bereich eine absolut anerkannte professionelle Lösung, die in Sachen Geschwindigkeit in der Lage ist, die fetten Varianten deutlich hinter sich zu lassen. Natürlich wird das an der einen oder anderen Stelle bedeuten, sich die erforderlichen Lösungen selbst zu konfigurieren. Ein pures Verwenden von KVM würde das soger noch steigern. Weiterer Vorteil: Durch die abermalige stringente Konzentration auf den konkreten Anwendungsfall bietet sich bei dem ergänzenden Lösungsbedarf zusätzliches Einsparpotential im Sinne einer bestmöglichen Leistungsoptimierung.
NUR: Was helfen mir diese ganzen Bewertungsüberlegungen und "Herabqualifizierungen", wenn DIE URSACHE DES PROBLEMS außerhalb des Einflussbereichs des Hosts, der VM, des Hypervisors und - meinetwegen ganz konkret auch - der Bridge liegt? Die Bridge / der virtuelle Switch ist doch nicht das Problem, sondern das äußere Scheitern der DHCP-Requests beim AP.
ODER: Werfen wir doch zum sachlichen Vergleich einen Blick auf einen namhaften Hypervisior außerhalb der Linux-Welt: Hyper V. Auch dort kann ich lediglich einen virtuellen Switch erstellen und die VM(s) nebst einer/mehrerer (W)LAN-Karte(n) anbinden. Mithin würde selbst Hyper V - jedenfalls nativ mit Boardmitteln - AN DEM HIESIGEN PROBLEMS SCHEITERN. Folglich muss auch dort eine außerhalb von Hyper V liegende oder eine Addin-Lösung gefunden werden. Nichts anderes als hier!
Für das Bereitstellen einer konkreten VM bin ich ganz bei Dir, weil es insoweit völlig egal ist, welcher Hypervisor verwendet wird. Immerhin hat die vom Hypervisor verantwortete Bereitstellung einer VM eher nichts oder nur peripher mit dem Vorgang der DHCP-gestützten Vergabe von IP-Adressen an den Host und die VM(s) zu tun.
VON DAHER: Kann VirtualBox die außerhalb des Hosts liegenden Beschränkungen der Verarbeitung von DHCP-Requests ernsthaft und effektiv überwinden??? Wenn das der Fall sein sollte, würde ich mich über tiefergehende Informationen sehr freuen! Dann könnte ein Wechsel in der Tat erwägungswert erscheinen, sofern sich ein solcher Lösungsansatz nicht unabhängig vom Hypervisor realisieren ließe. Ich bin da ganz offen für alles ...
Ungeachtet dessen dürftest Du übersehen, dass das Notebook kein Server ist, dessen Lebensinhalt in der Existenz als Hypervisor liegt, und auch nicht als solcher "missbraucht" wird. Beide - Host und VM - sollen gleichzeitig und unabhängig voneinander in die Umwelt gehen können. Deswegen ist ein ausschließliches Fokussieren nur auf die VM neben der Sache liegend. Das nur zur nochmaligen Klarstellung des Anwendungsszenarios. Wäre es ein Server oder als ein solcher gedacht, dann wäre ich abermals ganz bei Dir, über den Einsatz einer komplexeren Hypervisor-Lösung wie Hyper V, Xen Hypervisor etc. nachzudenken, sofern die zwischenzeitlichen Erfahrungen mit QEMU keine andere Entscheidungsrichtung vorgeben.
Jetzt aber wieder zurück zu DEM HIESIGEN PROBLEM ...
Viele Grüße
HansDampf06
Du "beschimpfst" die originäre Kernel-Implementierung aller aktuellen Linux-Varianten: KVM. Alle namhaften Hypervisoren auf Linux-Basis nutzen das nebst Teilen von QEMU unter der Haube - KVM(/QEMU) ist so zu sagen die native(ste) VM-Unterstützung. Und das soll wirklich ein gruseliger Hypervisor sein? Die anderen sind doch - zugespitzt ausgedrückt - nur eine Shell um KVM ...
Freilich kann ein FETTER Xen Hypervisor verwendet werden, der - windowsgleich - das schlanke Debian aufbläst ... Dennoch ist QEMU aufgrund seiner zentralen Stellung in diesem Bereich eine absolut anerkannte professionelle Lösung, die in Sachen Geschwindigkeit in der Lage ist, die fetten Varianten deutlich hinter sich zu lassen. Natürlich wird das an der einen oder anderen Stelle bedeuten, sich die erforderlichen Lösungen selbst zu konfigurieren. Ein pures Verwenden von KVM würde das soger noch steigern. Weiterer Vorteil: Durch die abermalige stringente Konzentration auf den konkreten Anwendungsfall bietet sich bei dem ergänzenden Lösungsbedarf zusätzliches Einsparpotential im Sinne einer bestmöglichen Leistungsoptimierung.
NUR: Was helfen mir diese ganzen Bewertungsüberlegungen und "Herabqualifizierungen", wenn DIE URSACHE DES PROBLEMS außerhalb des Einflussbereichs des Hosts, der VM, des Hypervisors und - meinetwegen ganz konkret auch - der Bridge liegt? Die Bridge / der virtuelle Switch ist doch nicht das Problem, sondern das äußere Scheitern der DHCP-Requests beim AP.
ODER: Werfen wir doch zum sachlichen Vergleich einen Blick auf einen namhaften Hypervisior außerhalb der Linux-Welt: Hyper V. Auch dort kann ich lediglich einen virtuellen Switch erstellen und die VM(s) nebst einer/mehrerer (W)LAN-Karte(n) anbinden. Mithin würde selbst Hyper V - jedenfalls nativ mit Boardmitteln - AN DEM HIESIGEN PROBLEMS SCHEITERN. Folglich muss auch dort eine außerhalb von Hyper V liegende oder eine Addin-Lösung gefunden werden. Nichts anderes als hier!
Nebenbei:
Eine einfache und simple VirtualBox benötigt auch unter Linux keinerlei IP Adressen für interne vSwitches oder Bridges und würde deine Vorgabe im Handumdrehen mit nur einer Mac lösen. Keiner der gängigen Hypervisoren benötigt IPs für Bridges.
Mit einer VirtualBox würdest du also in jedem Falle allemal besser fahren, denn diese benötigt, wie es sein soll, nur eine Mac Adresse der VM. Die VM kann dann flexibel in jedes beliebige WLAN, egal welche SSID und Authentisierungsverfahren, wechseln.
Eine einfache und simple VirtualBox benötigt auch unter Linux keinerlei IP Adressen für interne vSwitches oder Bridges und würde deine Vorgabe im Handumdrehen mit nur einer Mac lösen. Keiner der gängigen Hypervisoren benötigt IPs für Bridges.
Mit einer VirtualBox würdest du also in jedem Falle allemal besser fahren, denn diese benötigt, wie es sein soll, nur eine Mac Adresse der VM. Die VM kann dann flexibel in jedes beliebige WLAN, egal welche SSID und Authentisierungsverfahren, wechseln.
Für das Bereitstellen einer konkreten VM bin ich ganz bei Dir, weil es insoweit völlig egal ist, welcher Hypervisor verwendet wird. Immerhin hat die vom Hypervisor verantwortete Bereitstellung einer VM eher nichts oder nur peripher mit dem Vorgang der DHCP-gestützten Vergabe von IP-Adressen an den Host und die VM(s) zu tun.
VON DAHER: Kann VirtualBox die außerhalb des Hosts liegenden Beschränkungen der Verarbeitung von DHCP-Requests ernsthaft und effektiv überwinden??? Wenn das der Fall sein sollte, würde ich mich über tiefergehende Informationen sehr freuen! Dann könnte ein Wechsel in der Tat erwägungswert erscheinen, sofern sich ein solcher Lösungsansatz nicht unabhängig vom Hypervisor realisieren ließe. Ich bin da ganz offen für alles ...
Ungeachtet dessen dürftest Du übersehen, dass das Notebook kein Server ist, dessen Lebensinhalt in der Existenz als Hypervisor liegt, und auch nicht als solcher "missbraucht" wird. Beide - Host und VM - sollen gleichzeitig und unabhängig voneinander in die Umwelt gehen können. Deswegen ist ein ausschließliches Fokussieren nur auf die VM neben der Sache liegend. Das nur zur nochmaligen Klarstellung des Anwendungsszenarios. Wäre es ein Server oder als ein solcher gedacht, dann wäre ich abermals ganz bei Dir, über den Einsatz einer komplexeren Hypervisor-Lösung wie Hyper V, Xen Hypervisor etc. nachzudenken, sofern die zwischenzeitlichen Erfahrungen mit QEMU keine andere Entscheidungsrichtung vorgeben.
Jetzt aber wieder zurück zu DEM HIESIGEN PROBLEM ...
Viele Grüße
HansDampf06
