[Wishlist] Support macvlan/macvtap interfaces

[Mike Pontillo]

In the future, customers may wish to use MAAS to deploy nodes with macvlan and/or macvtap interfaces.

Customers have previously worked around lack of support in ifupdown for these interface types by making use of pre-up and post-down scripts. (Which there is already a separate `netplan` bug for.)

But it would be nice to support these interface types natively.

[Mathieu Trudel-Lapierre (cyphermox)]

Is this a current wishlist for MAAS or was it implemented at all? How many users are requesting this feature? How would you use macvlan/macvtap devices?

[Mike Pontillo (mpontillo)]

This is not urgent for MAAS at this time, but I'll let you know if that changes.

[Steve Langasek (vorlon)]

For reference, an explanation of how macvlan differs from other currently supported interface types. https://sreeninet.wordpress.com/2016/05/29/macvlan-and-ipvlan/

[Gabriel Ramirez (gabriel1109)]

Per internal SF ticket #00175665, customer would also like to see this feature implemented in MaaS

[Phil Merricks (seffyroff)]

I use macvlan with LXD, and am expecting to adoption of bionic hosts/containers to begin rollout imminently. I can work around this with some manual trickery, but it's going to be a mess.

[Jean-Daniel Dupas (xooloo)]

I'm using macvlan to implement some IP redundancy scheme and while I can workaround the netplan limitation thanks to networkd-dispatch scripts, I would rather be able to create interface directly using netplan.

[DevX (palma-victor)]

I rather not have a hack to do this as well. This might force me to utilize another OS.

[Peter Salanki (salanki)]

+1 on this request

[Thiago Martins (martinx)]

This would be very useful when deploying OpenStack Ansible with systemd-nspawn! It uses MACVLAN interfaces.

+1 on this request!

[dann (ktdann)]

This link is 2nd in google search for "netplan macvlan"
1st link is about someone who gave up. :(

I'm waiting for this to be implemented.

+1 on this request

[Phillip Jolliffe (phill-jolliffe)]

Please add support for macvlan and ipvlan

[Sherman Yin (shermanyin)]

Wanting to use macvlan to set up docker containers with their own IP addresses on the network. As a result I have to set up macvlan on the host too for connectivity to the containers. Really want to use netplan but have to resort to startup scripts to manually reconfigure networking on reboots.

[Eddy G (eddyg)]

As suggested in the netplan FAQ, since macvlan support doesn't exist, you can switch back to `ifupdown`:

  https://netplan.io/faq#how-to-go-back-to-ifupdown

Hopefully this gets resolved someday...

[Thiago Martins (martinx)]

Hey guys, do this for Ubuntu 20.04, pleeeease! :-P

[rodalphoc (rodalphoc)]

Note you do not need to drop netplan entirely, you can run ifupdown for macVLAN (only) at the same time as using netplan for everything else. This is obviously an abomination that should be purified with cleansing fire, but it does work.

[Thiago Martins (martinx)]

Hello rodalphoc,

 I can't drop Netplan and move back to ifupdown.

 So, what I'm actually doing is something simpler...

 I'm creating the MACVLAN Interfaces using systemd files, then, using those interfaces directly on Netplan as if they where a regular network interface.

 Something like:

 https://gist.github.com/jooter/8f95555021d2a4e7cb6241368473ed55

 ...but even simpler. Google about "systemd macvlan"!

 I sincerely hope that this feature will make into Ubuntu 20.04!

Cheers!

[Bulk Adhesive (bulkadhesive)]

Like #10, I stumbled across this bug searching for "netplan macvlan". Hopefully the following helps anyone else that ends up here.

netplan handles nearly all of my current networking needs. However, I have a requirement to access Docker containers on a macvlan from the host (like #12). Rather than give up and revert back an alternative network configuration system (which seems to be the [officially endorsed solution](https://netplan.io/faq#how-to-go-back-to-ifupdown)), I'd like to stick with it.

Most solutions posted here and elsewhere focus on direct configuration of systemd-networkd as a way to get around the limitation. This is likely fine in Ubuntu Server where systemd-networkd is the default renderer, but my use case is the desktop where NetworkManager makes certain things easier. I'm not entirely certain adding systemd-networkd to the mix is a good idea in this case. (Or would even work; I'm interested to hear what is 'best practice' in this situation.)

Instead I'm making use of NetworkManager's [dispatcher scripts](https://developer.gnome.org/NetworkManager/stable/NetworkManager.html) to handle macvlan setup and teardown based on the state of the parent interface defined by netplan. Again this likely isn't the best or most elegant solution, so I'm open too feedback.

# /etc/NetworkManager/macvlan.sh
```
#!/usr/bin/bash

IFACE=${1}
ACTION=${2}

if [[ "${IFACE}" == "br0" && "${ACTION}" == "up" ]]; then
        ip link add link br0 name macvlan0 type macvlan mode bridge
        ip addr add 172.29.10.224/32 dev macvlan0
        ip link set macvlan0 up
        ip route add 172.29.10.224/27 dev macvlan0
fi

if [[ "${IFACE}" == "br0" && "${ACTION}" == "pre-down" ]]; then
        ip route del 172.29.10.224/27
        ip link set macvlan0 down
        ip link del dev macvlan0
fi
```

Then set appropriate ownership/permissions and symlink to the hook locations

    $ chown root:root /etc/NetworkManager/macvlan.sh
    $ sudo chmod 700 /etc/NetworkManager/macvlan.sh
    $ sudo ln -s /etc/NetworkManager/macvlan.sh /etc/NetworkManager/dispatcher.d/pre-up.d/macvlan.sh
    $ sudo ln -s /etc/NetworkManager/macvlan.sh /etc/NetworkManager/dispatcher.d/pre-down.d/macvlan.sh
    $ sudo ln -s /etc/NetworkManager/macvlan.sh /etc/NetworkManager/dispatcher.d/no-wait.d/macvlan.sh
    $ sudo ln -s /etc/NetworkManager/macvlan.sh /etc/NetworkManager/dispatcher.d/macvlan.sh

It'd be nice if netplan supported creation and management of macvlan/ipvlan interfaces so this kind of abomination and others like it (#15) aren't required.

[Thiago Martins (martinx)]

Hey guys, here is my workaround with Netplan:

---
$ cat /etc/networkd-dispatcher/routable.d/10-macvlan-interfaces.sh
#! /bin/bash

ip link add macvlan0 link eth0 type macvlan mode bridge
ip link add macvlan1 link eth0 type macvlan mode bridge
---

Then, I can use the `macvlan[0|1]` interfaces on Netplan as regular "ethernets"!

There is a Reddit post about trying to do this with `systemd-network` but, not there yet:

https://www.reddit.com/r/systemd/comments/k17jcf/how_to_create_macvlan_interfaces_with/

[John Wohlers (john-wohlershome)]

Building on #18
I got the whole process working using netplan. For anyone needing a little more details

$ cat /etc/networkd-dispatcher/routable.d/10-macvlan-interfaces.sh
#! /bin/bash

ip link add macvlan0 link eth0 type macvlan mode bridge
----
$ cat /etc/netplan/docker.yaml
network:
    version: 2
    renderer: networkd
    ethernets:
        macvlan0:
            addresses:
                - 192.168.1.6/32
            routes:
                - to: 192.168.1.2/31
                  via: 192.168.1.6
                  metric: 100
                - to: 192.168.1.4/31
                  via: 192.168.1.6
                  metric: 100
----
Set the script to be executable "chmod o+x,g+x,u+x /etc/networkd-dispatcher/routable.d/10-macvlan-interfaces.sh"
----
Apply the changes:
netplan apply

[Frank Seidinger (fseidinger)]

The original post was about support for macvlan on MaaS. I guess that this lead to the conclusion that mavlans are not of high priority. This also lead to the fact that this issue is more than seven years old and that means it is open for nearly three consecutive LTS versions.

From my point of view, the original use case shifted from supporting MaaS only to supporting macvlans in general. This is due to the fact that using docker container with lots of software that have special needs (like discovery) and are running best with macvlans.

Whereas macvlan is perfectly supported with persistent durability, the host OS does not. This is the main use case people asking and searching for. Simply add communication from host OS to container using macvlan interfaces.

I guess, that it might be helpful to file an additional issue referencing that use case.

[Matthias Harter (hartimcwildfly)]

Sorry, just wanted to read the legend

[Aaron Knauf (unnecessary-trouble)]

To add to #19, you might want to put 10-macvlan-interfaces.sh in /etc/networkd-dispatcher/configured.d/, else when the underlying interface doesn't get assigned an address, the macvlans won't be created.

[willzhang (willubt)]

I test this, it work for macvlan.

networkd config
```
cat >/etc/networkd-dispatcher/routable.d/10-macvlan-interfaces.sh<<EOF
#! /bin/bash
ip link add macvlan0 link enp1s0 type macvlan mode bridge
ip link add macvlan1 link enp1s0 type macvlan mode bridge
EOF
chmod o+x,g+x,u+x /etc/networkd-dispatcher/routable.d/10-macvlan-interfaces.sh
```

netplan config

```
root@ubuntu:~# cat /etc/netplan/00-installer-config.yaml
network:
  ethernets:
    enp1s0:
      dhcp4: false
      addresses:
        - 172.16.10.10/24
      nameservers:
        addresses:
          - 223.5.5.5
          - 223.6.6.6
      routes:
        - to: default
          via: 172.16.10.1
    macvlan0:
      addresses:
        - 172.16.10.11/24
    macvlan1:
      addresses:
        - 172.16.10.12/24
  version: 2
```

apply
```
netplan apply
```

check macvlan interface

```
root@ubuntu:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 7c:b5:9b:59:0a:71 brd ff:ff:ff:ff:ff:ff
    inet 172.16.10.10/24 brd 172.16.10.255 scope global enp1s0
       valid_lft forever preferred_lft forever
13: macvlan0@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 32:e8:b4:0a:47:62 brd ff:ff:ff:ff:ff:ff
    inet 172.16.10.11/24 brd 172.16.10.255 scope global macvlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::30e8:b4ff:fe0a:4762/64 scope link
       valid_lft forever preferred_lft forever
14: macvlan1@enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d2:73:75:14:b2:04 brd ff:ff:ff:ff:ff:ff
    inet 172.16.10.12/24 brd 172.16.10.255 scope global macvlan1
       valid_lft forever preferred_lft forever
    inet6 fe80::d073:75ff:fe14:b204/64 scope link
       valid_lft forever preferred_lft forever
```