macvlan driver doesn't work in MacOS

[ajoldham]

Continuation of : #3447 as it was auto-closed. This isn't fixed in the latest Docker Edge 19.03.2 with MacOS 10.14.6.

---

$ ifconfig en9
en9: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=4<VLAN_MTU>
ether 58:ef:68:7d:06:05
inet6 fe80::1028:71b1:5694:b4bf%en9 prefixlen 64 secured scopeid 0x12
inet 10.42.34.91 netmask 0xfffffc00 broadcast 10.42.35.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT )
status: active
$ docker network create -d macvlan --subnet=10.42.32.0/22 --gateway=10.42.32.1 -o parent=en9 pub_net
Error response from daemon: invalid subinterface vlan name en9, example formatting is eth0.10

[maxpavlov]

+1

If you specify eth0 in parent, it will get created, but won't work =)

[ViperRNMC]

same problem here with en0

[adocehic]

I've been losing my mind in various attempts in getting macvlan working, and this is why. Blindly using eth0 instead of the actual en0 interface appears to work when it shouldn't.

[obmuc]

Any workarounds for this?

[HunterDG]

following

[amaisano]

Still not working in Docker 2.2.0.4.

[adocehic]

I ended up buying a Dell R620. It was easier to actually set up a whole linux server to really take advantage of Docker than it was to waste time working around this bug or waiting for it to get fixed. It's rather annoying as this is a very clear and reproducible bug that on the surface appears to be simple.

…

On Jan 7, 2020, at 2:19 PM, obmuc ***@***.***> wrote: Any workarounds for this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3926?email_source=notifications&email_token=ABUXDOJHGHKJO523LWEJ7NLQ4T5VPA5CNFSM4I2V6M62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIKPQFA#issuecomment-571799572>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUXDOKNKYUF7D7JAQ6RSP3Q4T5VPANCNFSM4I2V6M6Q>.

[amaisano]

@adocehic are you saying typing eth0 actually works with en0 (even though it shouldn't)?

[mastix]

I can confirm that it's still not working with Docker Desktop 2.2.0.5 & Docker 19.03.8.

[rfoltz]

@mikeparker I think we would really wish for this to be implemented for Mac OS, this is stopping me from using Docker in my home lab.

[dciancu]

Still not working with Docker Desktop 2.3.0.4 & macOS 10.15.6

[dinhkk]

docker network create -d macvlan \
  --subnet=192.168.2.0/24 \
  --gateway=192.168.2.1 \
  -o parent=eth0 \
  my-macvlan-net

I have tested above command on my macOSX 10.15.6. This seems to be a lie. It works. But ifconfig does not show eth0, but en0

[ajoldham]

Thanks. It seems to configure, but when I run a container using that network, I can't seem to ping or communicate out of it.

[ctyrider]

Yes, macOS Docker allows configuring macvlan bound to parent eth0 interface (which doesn't exist on the host). Multiple Containers placed in that macvlan can communicate with each out, but not out of the host.. which is what I would expect when binding a network to a phony adapter.

Any thoughts on when we can actually see this fixed? Disappointing that core Docker feature like this doesn't work on macOS.

[Alexivia]

This would be such a useful feature... I can confirm that on my Mac I can't configure a macvlan network interface with Docker version 19.03.13, build 4484c46d9d.

[michaelprescott]

It's looking like this bug might not be getting fixed for a while. What are other options? How else can we configure and launch a set of containers via 'docker-compose up' to make them accessible to other machines on a LAN?

[michaelprescott]

And, same failure for ipvlan. I wish Docker docs made this bold and clear that both are broken on macOS. I learned a lot trying to solve it, but ultimately it was a waste of time for me.

It takes a little longer to setup what I need with VMs and VMWare Fusion, but it works. Interestingly, in Fusion it's categorized under the "Bridged Networking" configuration. Noting that, I circled back to Docker and tried setting up a bridged network. Still no luck. The containers still don't appear on the LAN. Anyhow, if you are free to move to a linux development machine where macvlan and ipvlan work, here are some really great articles about macvlan https://hicu.be/tag/macvlan

[mminks]

Confirmed.

[onlinefchen]

Confirmed.

waiting

[docker-robott]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[barinet]

/lifecycle frozen

[barinet]

/remove-lifecycle stale

[Rubberduck1971]

/remove-lifecycle stale

[Rubberduck1971]

/lifecycle frozen

[fdevans]

+1

[pkishino]

+1

[encbladexp]

No Idea why this Ticket is that long open, but:

The macvlan networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

From the Official Docs

[enzofrnt]

No Idea why this Ticket is that long open, but:

The macvlan networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.

From the Official Docs

Not sure when it was update but in some documentation it was not clear that only linux support it.
But any way, because we ask to get support of it on MacOS especially with the new ARM that are freaking efficient

[encbladexp]

It is a hard technical limitation of using virtualisation on macOS and Windows. You just don't have access to a host's network interface through the used virtualisation, neither Hyper-V (Windows) nor HyperKit (macOS) support to be attached directly to a hosts interface. And that is what you would need.

I created a repository, just for fun reasons: Docker Test Network on Github.

The efficiency of ARM is related to ARM stuff, as soon as you need an x86/amd64 image, things get much less efficient, by design.

Guidance: Close this ticket, and open one for HyperKit, because that is the place where things would need to be "fixed", but be aware: HyperKit is based von Hypervisor.Framework from Apple, its possible that this Framework just lacks features needed, which would result in a call towards the Apple Support. Good luck. 🍀

[Neo-OuO]

+1

[CaptainRedHat]

Well this is unfortunate news as I was looking to using a Mac mini as my homelab’s master development workstation and docker host for things that don’t work well in k8s. However, I might try a hacky workaround involving a WireGuard vpn. (I’m thinking if I use WireGuard to bridge the Linuxkit vm’s network to my physical network, I could theoretically make the docker internal network routable from the physical network).

[enzofrnt]

Well this is unfortunate news as I was looking to using a Mac mini as my homelab’s master development workstation and docker host for things that don’t work well in k8s. However, I might try a hacky workaround involving a WireGuard vpn. (I’m thinking if I use WireGuard to bridge the Linuxkit vm’s network to my physical network, I could theoretically make the docker internal network routable from the physical network).

Yes, if you do it. Please provide us the solution.
Thanks !

[michaelprescott]

It is a hard technical limitation of using virtualisation on macOS and Windows. You just don't have access to a host's network interface through the used virtualisation, neither Hyper-V (Windows) nor HyperKit (macOS) support to be attached directly to a hosts interface. And that is what you would need.

I created a repository, just for fun reasons: Docker Test Network on Github.

The efficiency of ARM is related to ARM stuff, as soon as you need an x86/amd64 image, things get much less efficient, by design.

Guidance: Close this ticket, and open one for HyperKit, because that is the place where things would need to be "fixed", but be aware: HyperKit is based von Hypervisor.Framework from Apple, its possible that this Framework just lacks features needed, which would result in a call towards the Apple Support. Good luck. 🍀

How it is achieved and how it runs so well on both Windows and Linux platforms is magic to me, but for each, the performance is amazing and good enough for my usage. There are a lot of us that use macOS, and the new Mac Mini's are absolutely amazing. At the present I'm still working around the matter by just using VMWare VMs, and built my own IaC tool for ramping up and configuring new machines. One Mac mini is now running about 6 VMs with my current setup, however, I suspect Docker containers would be even more performant. So, I would hope they don't close this ticket and get it resolved one day. For that reason, I come back here and checkup on status from time to time.

[encbladexp]

Just in case: AFAIK is macvlan also not working on Windows, because as I said: It is a VM, sitting on a Bridge, on every OS except on Linux where Docker has its home. And even on Linux, its possible to install a mess called Docker Desktop, which nobody asked for and nobody really needed there.

[jkneer]

The situation is a usability nightmare. Docker is offered on multiple platforms, and I have actually used docker on Linux, macos and windows for years, before running into this issue. I spend hours debugging, until I found the hint in the documentation that what I wanted to do was unsupported.

I do understand the technical reasoning why some features are not implemented on macos and windows. But that was - at least not my complaint - the problem is the silent failure. The CLI parameters are there but they fail silently, no warning nothing. As you can see in this thread, this has probably wasted thousands of hours.

The solution is quite simple: There should be either a very prominent warning upon usage of the CLI parameters, or they should be removed on the unsupported platforms. I would prefer the removal of the parameters, especially as there seems no larger interest in ever supporting the features on those platforms.

[encbladexp]

In that case @jkneer the server/daemon would need to inform the CLI/client that this feature is unsupported. The parameter itself could not be remove from the client, as you could use any Docker daemon by using either docker context or setting DOCKER_HOST explicitly.

[g10ck]

I've resolved my issue. It's not regarding to macvlan, but I've found this issue after searching an ability to connect to my containers directly. If you are here for the same reason then my solution can be helpful for you.

What was the problem: I was testing dev environment and my app has the same ports in each container. I didn't want to do port mapping for each service like: 22 ssh in container ONE to 23 local, 22 ssh on container TWO to 24 local, ... And ssh was not the case, other services had also the same ports in each container. So I wanted to reach my containers by their ip-addresses and ports directly.

Solution:

1. Get subnet that is bridget to host network. In my case bridge name in MacOS was "bridge100":
   bridge_name="bridge100" brnet=$(ifconfig $bridge_name | egrep -o 'inet.*netmask' | cut -d' ' -f 2 | awk -F'.' '{print $1"."$2"."$3}') && echo $brnet
2. Get iface address in docker VM in MacOS:
   gateway=$(echo "ifconfig | grep $brnet && exit" | nc -U ~/Library/Containers/com.docker.docker/Data/debug-shell.sock 2>/dev/null | egrep -o 'inet.*netmask' | cut -d' ' -f 2) && echo $gateway
   3, Get docker containers network address:
   containers_net=$(echo "ifconfig docker0 && exit" | nc -U ~/Library/Containers/com.docker.docker/Data/debug-shell.sock 2>/dev/null | egrep -o 'inet.*netmask' | cut -d' ' -f 2 | awk -F'.' '{print $1"."$2".0.0/16"}') && echo $containers_net
3. Add route from MacOS to docker container network (which is NATed) via bridget interface on docker VM side:
   sudo route add $containers_net $gateway
4. Enjoy

[encbladexp]

@g10ck that is a different use case. You are basically just routing the container networks which exist within the VM from the host into the VM, that will (most likely as you showed) work.

However, it is not a solution to provide containers IPs on the hosts network itself.

[matthew-ewing]

+1

[NickFall]

posting in an epic thread

Hi all - we'll investigate this in our next sprint, commencing Monday 15-August. I'll post back here with an update shortly.

@christophermclellan did said discussion ever happen? the promised update sure didn't
@akerouanton please lead us out of this darkness

[enzofrnt]

posting in an epic thread

Hi all - we'll investigate this in our next sprint, commencing Monday 15-August. I'll post back here with an update shortly.
@christophermclellan did said discussion ever happen? the promised update sure didn't
@akerouanton please lead us out of this darkness

Does that mean that they are working on it ?!

[spamshaker]

6.10.2024
Error response from daemon: invalid subinterface vlan name en0, example formatting is eth0.10
Docker version 27.3.1, build ce1223035a

[akerouanton]

Does that mean that they are working on it ?!

No, not yet. We probably need to use an under-documented macOS feature which is gated behind an entitlement that need to be granted by Apple Developer Support on a case-by-case basis. We've filled the required paperwork for that and are currently waiting for Apple's approval. Afterward, we'll need some time to do exploratory work, etc...

We'll also need to weigh up and prioritize this feature request against other features we've in our backlog. But we hear you, and we know this issue ranks first in terms of reactions / comments.

[enzofrnt]

Does that mean that they are working on it ?!

No, not yet. We probably need to use an under-documented macOS feature which is gated behind an entitlement that need to be granted by Apple Developer Support on a case-by-case basis. We've filled the required paperwork for that and are currently waiting for Apple's approval. Afterward, we'll need some time to do exploratory work, etc...

We'll also need to weigh up and prioritize this feature request against other features we've in our backlog. But we hear you, and we know this issue ranks first in terms of reactions / comments.

Nice to read that, thanks you !
Don't forget that new mac are pretty impressive in energy efficiency and unlocking those capabilities will be a key to use those Mac as "Server".

[enzofrnt]

Is docker VMM on macos a step forward ?

[michaelprescott]

Is docker VMM on macos a step forward ?

Can you clarify, please? I'm not sure what you mean. Has it been fixed?

I've been following this thread, well, forever it seems because it is a desired, and I'd argue, necessary feature, and it works on other platforms, but not on Mac. Unless something has changed in the last 3 weeks.

While there are several reasons others might want this feature to work properly, I'd like it for the simplest of reasons, and that is so I can test apps, services, that I create from multiple devices within my LAN, and I want my other LAN services to be able to hand out appropriate IPs and other configuration to the docker machines. As things have been, I'm entirely constrained to my Mac development machine for testing, which doesn't do a great job of recreating client environments like my iPad, phone, TV, and other client app platforms. So, VMware is still proving to be the best solution for my use case for now.

[enzofrnt]

Is docker VMM on macos a step forward ?

Can you clarify, please? I'm not sure what you mean. Has it been fixed?

I've been following this thread, well, forever it seems because it is a desired, and I'd argue, necessary feature, and it works on other platforms, but not on Mac. Unless something has changed in the last 3 weeks.

While there are several reasons others might want this feature to work properly, I'd like it for the simplest of reasons, and that is so I can test apps, services, that I create from multiple devices within my LAN, and I want my other LAN services to be able to hand out appropriate IPs and other configuration to the docker machines. As things have been, I'm entirely constrained to my Mac development machine for testing, which doesn't do a great job of recreating client environments like my iPad, phone, TV, and other client app platforms. So, VMware is still proving to be the best solution for my use case for now.

That not fix. But Docker VMM maybe a step forward to see this implemented.

[victorwads]

Still need it be to fixed @docker-robott

[GiamBoscaro]

Just found out this today. I have seen very old posts about this. Incredible that this was not fixed in years and years.

[enzofrnt]

Just found out this today. I have seen very old posts about this. Incredible that this was not fixed in years and years.

this was not in the documentation sometime ago..

[GiamBoscaro]

Just found out this today. I have seen very old posts about this. Incredible that this was not fixed in years and years.

this was not in the documentation sometime ago..

I have seen posts from 2020 with people complaining about this problem in macOS.