[Wishlist] Support macvlan/macvtap interfaces

Bug #1664847 reported by Mike Pontillo on 2017-02-15
This bug affects 19 people
Affects Status Importance Assigned to Milestone

Bug Description

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.

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?

Changed in netplan:
status: New → Triaged
importance: Undecided → Wishlist
Mike Pontillo (mpontillo) wrote :

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

Steve Langasek (vorlon) wrote :

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) wrote :

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

Phil Merricks (seffyroff) wrote :

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) wrote :

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) wrote :

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

Peter Salanki (salanki) wrote :

+1 on this request

Thiago Martins (martinx) wrote :

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

+1 on this request!

dann (ktdann) wrote :

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

Please add support for macvlan and ipvlan

Sherman Yin (shermanyin) wrote :

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) wrote :

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


Hopefully this gets resolved someday...

Thiago Martins (martinx) wrote :

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

rodalphoc (rodalphoc) wrote :

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) wrote :

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:


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

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


Bulk Adhesive (bulkadhesive) wrote :

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


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

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

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers