-
Notifications
You must be signed in to change notification settings - Fork 880
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
macvlan / ipvlan parent interface (e.g. en0 instead of eth0) broken on Mac OSX #2614
Comments
yeah, I recently looked into using macvlans and stumbled upon this..quite surprised this hasnt been fixed yet.. |
+1 |
8 similar comments
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 Anyone has a solution? |
+1 |
1 similar comment
+1 |
Unfortunately, the documentation specifies it not supported (yet?) on Windows and MacOS : https://docs.docker.com/network/network-tutorial-macvlan/ |
+1 |
I was supprised that this issue hasn't been solved for such a long time. |
Yeah having similar issues with an ubuntu installation - neither network adapter gets a standard name |
since macvlan not supported on MAC OSX, I ended up to use macvlan via multipass on OSX |
same issue here: just installed docker desktop, on ubuntu 23.04. So this is all newer versions of docker... The process of installing docker desktop seemed to kill / destroy existing containers, and existing docker network definintions. So when trying to re-create the docker network. With same commands as had always worked before... Error response from daemon: invalid subinterface vlan name enp4s0f1, example formatting is eth0.10 It has broken / regressed. |
I believe that this bug might be related with the following changeset: for sure, the bug occurs here:
Maybe if the
the ??? [REASON FOR EDIT] the repo code was moved to other repo now: (but is same exact code) |
maybe can you help us understand this bug @arkodg ? Sorry I am not familiar with go code, and these library functions that is being called out to. However this seems like where the error is happens. For any systems with an interface name... which isn't That the call BTW this code is duplicated between both the ipvlan and macvlan driver backends, if andthing needs fixing there too. Otherwise perhaps it is the underlying common library function is calling out to and failing to return the correct answer? (that, for example: |
OK. So here are some candidate bugs for the upstream library (the netlink is maintained by somebody else...) However just don't have here the visibility (knowledge) to check which specific version of the netlink library my local docker installation was compiled to be using here. And I don't really have this same level of familiarity to go in here and try recompiling this macvlan driver from the git / to try with speculative edits and so on to those critical code path. To test out these theory. And give clearer answers But until then... my docker is totally broken :( Of course I can still provide some extra infos (such as specific docker version, exact kernel version). And follow some extra instructions / replace some binaries or .so file. It does not seem too challenging (at least not so far). Any further help is very much appreciated. And it seems "enough"? other people are affected? If indeed this matter was not fixed already? |
Seems like this issue was 1st reported all the ways back in 2019 perhaps? (but was never looked at) However this bug seems significant! I would recommend at least some look at it, if not should be considered looking towards critical / important / higher priority. Along those lines |
Documentation says this is not supported in Mac which sux. no idea why they cant fix it sicne 4 years. Just run into this issue and now looking into how i do i get a workaround with it. |
Any fixes? |
Having the same issue on my Macos Ventura 13.x.x |
same issue ... |
Did you get any workaround ? |
+1 |
1 similar comment
+1 |
While this repo is in a semi-archived state (only used by the Moby 20.10 branch), I am going to close this issue before the official archiving as it seems to be misleading people. libnetwork does not work natively on macOS; and the "issue" here is that because the networking code runs inside the Linux virtual machine of Docker Desktop, "native" networking modes like I'd suggested interested users consult docker/roadmap#238 and the many issues linked to it (e.g. for macvlan). |
It appears the docker macvlan / ipvlan drivers expect parent (host) interfaces to follow linux-like interface naming (e.g.
eth0
as a prefix) and break when faced w/ Mac OSX interface naming (e.g.en0
)When trying to set up a macvlan on Mac OSX w/ the primary network interface
en0
as so:docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=en0 pub_net
The attempt fails with:
Error response from daemon: invalid subinterface vlan name en0, example formatting is eth0.10
seelibnetwork/drivers/macvlan/macvlan_setup.go
Line 110 in d095108
When trying to set up a 802.1q trunk macvlan as so:
docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=en0.86 pub_net_86
The attempt fails with:
Error response from daemon: -o parent interface does was not found on the host: en0
seelibnetwork/drivers/macvlan/macvlan_setup.go
Line 155 in d095108
The same commands execute without complaint when
eth0
instead ofen0
is used, but sinceeth0
doesn't actually exist on the host, the containers are isolated from the network.This issue was raised in docker/for-mac#3926 but probably didn't get any visibility there. Hopefully it'll get noticed here.
The text was updated successfully, but these errors were encountered: