[systemd-devel] systemd-nspawn: cannot join existing macvlan

[Lennart Poettering]

On Sat, 30.05.15 19:55, Kai Krakow (hurikhan77 at gmail.com) wrote:

> The next issue with your argument is: AFAIR nspawn doesn't create a macvlan 
> interface based on the machine name. You have to pass the name of a physical 
> interface which transports this macvlan. The man page at least states that 
> you use an existing physical interface:

True, I was a bit confused there...

> 
>     --network-macvlan=
>         Create a "macvlan" interface of the specified Ethernet network
>         interface and add it to the container. A "macvlan" interface is a
>         virtual interface that adds a second MAC address to an existing
>         physical Ethernet link. The interface in the container will be named
>         after the interface on the host, prefixed with "mv-". Note that
>         --network-macvlan= implies --private-network. This option may be
>         used more than once to add multiple network interfaces to the
>         container.
> 
> Trying to nspawn a macvlan without giving a physical device results in "no 
> such device":
> 
> # systemd-nspawn --boot --link-journal=try-guest --machine=gentoo-mysql-base 
> --network-macvlan=
> systemd-nspawn: option '--network-macvlan' requires an argument
> 
> # systemd-nspawn --boot --link-journal=try-guest --machine=test --network-
> macvlan=test
> Spawning container test on /var/lib/machines/test.
> Press ^] three times within 1s to kill container.
> Failed to resolve interface test: No such device
> 
> So your assumption about macvlan seems to be incorrect. The other network 
> types may be based off the machine name but it doesn't work this way with 
> macvlan.

Yeah, nspawn creates a n interface "mv-foo" from a network interface
"foo" on the host.

> So I wonder what the purpose of macvlan is if you can only create one 
> machine using macvlan on my single physical link - and that's it?

I am not sure I follow. The mv-foo interface will be part of the
container, not the host. That means if you run 10 containers, all with
--network-macvlan=foo, then they each will have an interface called
"mv-foo", but with a different ifindex each. Or are you suggesting
that that's currently broken?

> I think the logic is wrong here in systemd-nspawn. Instead of trying to 
> create the host-side macvlan itself it should insist of it being there 
> already (to have one well-defined state to start with, and only optionally 
> create it by itself). Then, it can join multiple machines to the same 
> macvlan.

I don't grok this?

"the same macvlan"? 

> I'm using the following networkd config on the host to define this "well-
> defined state", enabling the host to also communicate through macvlan:
> 
> # cat /etc/systemd/network/10-macvlan.{netdev,network}
> [NetDev]
> Name=mv-enp5s0
> Kind=macvlan
>
> [MACVLAN]
> Mode=bridge
> #----------------
> [Match]
> Name=en*
> 
> [Network]
> MACVLAN=mv-enp5s0
> LinkLocalAddressing=no
> DHCP=no
> 
> If I remove this I am able to start one of the containers, but not two or 
> more. If I use this I am not able to start any macvlan container.

I have the suspicion that the confusion here stems from the fact that
nspawn creates the macvlan iface on the host first, then moves it into
the container. but if you already have an iface by that name on the
host, then it cannot create the macvlan under that name.

I figure we can fix that by creating the iface under a random name
first on the host, then move it into the container, and then rename it
to the right name afterwarads.

A work-around would be to name the .netdev iface of yours something
else than "mv-enp5s0", call it "waldi" or so, so that it doesn't
conflict with the name for the contaainer in the short time-frame that
the iface nspawn creates exists on the host...

Can you verify if such a change fixes your issue? If so, we can
randomoize the name initially, as sugegsted above.

Lennart

-- 
Lennart Poettering, Red Hat