@anderbytes Which parameters would you recommend to be able to set when creating a macvlan network? Right now I have name, subnet, gateway and parent. Anything you feel missing?
I don't miss anything, either.
Maybe something will show up after releasing it to public.
Nonetheless, one of the main features that have to be working so the "network" can be called OK, in my opinion, is that each container can reach other container via it's name, not raw IP.
Sent from my ASUS_Z017DA using Tapatalk
Agree with @anderbytes - I did notice this odd behavior. I thought maybe something was just wrong with my setup, so I created DNS names to resolve to the individual containers (but this is on the physical network) to make this easier. Glad to hear though that it may simply be something related to the actual plugin config.
@nicjo814 On the macvlan side, I will say that it was a bit tricky originally getting it all configured and understanding that gotchas. Once I figured out creating it manually, I did have to specify the IP (for each container) manually as I was putting it on a real network. It did require setting the IP range for the network, and it did have to be in a real operating network (aka one that exists with gateway etc). The other gotcha that may come into play here, is that when you setup the macvlan network, you can no longer reach the local host from the containers. This is for security purposes. So if you're saying you can't get outbound, make sure to test the actual gateway or something else, not just the local host route. I believe yes this will also affect "localhost" interface as well.
@subzero79 I noticed that the changelog looked "strange". Did you use omv-dch to increment it or the "standard" dch program? The omv-dch script wraps the dch program and adds some standard text to the changelog.
The wrapper can be found here: https://github.com/OpenMediaVa…b/master/usr/sbin/omv-dch
Yes, at the beginning i added a changelog, then i realized that I shouldn't do it, since is the maintainer or builder job to add it to the debian folder
I can't make macvlan work on my VirtualBox dev environment (in Ubuntu). Anyone have this working?
EDIT: The network interface gets created ok withing the container. However I can't access the outside.
I'm using the PCnet Fast III adapter in promiscuous mode and have tested both bridged and NAT mode... Running out of ideas
I am having trouble also with this, my testing is in proxmox. The vm i develop resides in a separate vlan, but there is intervlan routing in my lan, pretty sure this was working, no idea why it stopped now. As for now i am only getting inter container communication only, i cannot ping router, or any other lan resources even on the same vlan
Nonetheless, one of the main features that have to be working so the "network" can be called OK, in my opinion, is that each container can reach other container via it's name, not raw IP.
I don't understand this part. Could you elaborate on how this could be accomplished? Myself I run almost all my containers in macvlan mode and give them names via my DNS server.
I don't understand this part. Could you elaborate on how this could be accomplished? Myself I run almost all my containers in macvlan mode and give them names via my DNS server.
I don't have a DNS server and today am forced to use "--link" so they can reference each other without using IP, because it can change every Docker restart.
Of what I've read of Docker networks, any non-default bridge network creates a internal DNS server for those containers, making transparent this job of managing names.
So, I don't know if macvlan are required or just other network creations, but my goal is to reference containers by name without creating a whole DNS server outside just for that.
I don't understand this part. Could you elaborate on how this could be accomplished? Myself I run almost all my containers in macvlan mode and give them names via my DNS server.
I don't have a DNS server and today am forced to use "--link" so they can reference each other without using IP, because it can change every Docker restart.
Of what I've read of Docker networks, any non-default bridge network creates a internal DNS server for those containers, making transparent this job of managing names.
So, I don't know if macvlan are required or just other network creations, but my goal is to reference containers by name without creating a whole DNS server outside just for that.
I don't have a DNS server and today am forced to use "--link" so they can reference each other without using IP, because it can change every Docker restart.
Of what I've read of Docker networks, any non-default bridge network creates a internal DNS server for those containers, making transparent this job of managing names.
So, I don't know if macvlan are required or just other network creations, but my goal is to reference containers by name without creating a whole DNS server outside just for that.
Sent from my ASUS_Z017DA using Tapatalk
i was not aware of that feature to reference by name within the same network. According to the docs it should probably work if you specify a new bridged network too. Could you try this out and report back?
Not very soon. It may take a while. Busy.
Sent from my ASUS_Z017DA using Tapatalk
Had one of those moments....I was creating the network with -o --parent=ens18 
Is working now....from what i read in the docker docs host-container communication is not permitted, in the development stage of macvlan network in docker this was permitted apparently using a macvlan bridge in the host.
Adding in to what @anderbytes mentioned - this is true. This backend communication mechanism is used to ease communication between containers. It's a non-external accessible network. So as to say an external system isn't able to reach the containers by their names, but inter-container communication is easily facilitated this way. This is intended to simplify the task of networking/linking containers that rely on each other (such as a DB with an App, etc).
@SubZero - you are correct, host-container communication is not allowed. This is what I was meaning to illustrate in my earlier post. I'm not sure of a testing version which allowed communication, but then again I don't think i tested it when it was in testing! 
Glad to hear though that you got it working. By the looks of what you included for code, I believe that may have been your missing piece. You did need to give it a parent interface to get outbound communication. It is a tricky configuration overall to get ironed out properly. But when you get it right, it does provide a valuable functionality. For some time I actually used this to stop my smartphone system (OpenHAB) and Plex from contending with each other on ports trying to be established. I know generically you would think assigning ports via mappings would help, but not when they're not flexible and contend with UPnP requirements.
Long story short - it has its uses at times. So thanks for getting this etched out. It should provide valuable use for anyone deciding to leverage it.
It was never in the code by the way. My work only involve containers using macvlan networks, I had problems using creating the network using cli with a typo.
You can find in google some blog post about using macvlan network dated mid2016. I don't think is working any longer since they blocked at docker level.
@nicjo814 the tab looks ok to me. I am thinking of adding a "docker network connect" and disconnect button on the toolbar. i need to do more testing, to see if those are persistent changes.
connect and disconnect could really be handy to have.
Made some extra columns to the network tab
The connect button is I THINK working. I am going to work on the weekend on the disconnect button.
Nonetheless, one of the main features that have to be working so the "network" can be called OK, in my opinion, is that each container can reach other container via it's name, not raw IP.
I think you mean hostname, you're correct they can reach via hostnames in the same non-bridged network without this hostname registered by dhcp or statically mapped, but not by their names which is a property outside of the container.
The domain string is the network name
/ # nslookup 7de8ca989fa2
nslookup: can't resolve '(null)': Name does not resolve
Name:7de8ca989fa2
Address 1: 172.19.0.2 7de8ca989fa2.text123
/ #
Just reading the docker docs, efectively if you use --link option an Alias is put inside the host file pointing to the ip of the linked container.
I have a small feature request...
When creating a container it would be useful and a good way of getting insight/learning how docker container commandlines are built if there was a button to "View command line" that would show how the command is about to be built/run based on the setup the user has just built using the interface.
Don’t have an account yet? Register yourself now and be a part of our community!
