-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for bridged networking (e.g. to Wi-Fi) #342
Comments
A bridged interface have to use macOS's system bridge and by using that, you will lose the performance benefit of the orbstack's networking stack because that bridge is much slower than orbstack's. |
+1 for this. Homebridge is main usecase (for me). This example currently doesn't work in orbstack 0.17.1. Containers c1 and c2 have the right IP addresses, but there isn't a path from router to containers (or back). @kdrag0n mentioned elsewhere this is due to NATing in the vm. Also, docker complains about the parent interface 'en0', and expects it in the format 'eth.XX', which is linuxese. I suspect this is a feature of the libnetworking library. To be thorough, i also added a added a 'static' ARP route in my gateway setup, to aid external discovery, but that was probably premature. |
+1 for any HAP projects. Homebridge/Scrypted (HomeKit Plugin)/HomeAssistant (HomeKit Integration) |
+1 |
1 similar comment
+1 |
For Docker containers NAT is ok, but for VMs NAT isn't always the best joice. Continue using Multipass. |
+1 please 🙏 |
Add an option to bridge machines and containers (via
macvlan
) to an external network interface, such as the host Mac's Wi-Fi or Ethernet. This would make Linux machines and Docker containers appear as devices on the LAN.This is not the best networking method in most cases, so it won't be the default and generally wouldn't be recommended unless necessary. There will always be inherent compatibility issues with certain networks, for example.
The text was updated successfully, but these errors were encountered: