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

[Tom Gundersen]

On Thu, Jun 18, 2015 at 9:10 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

Hm, you sure about this? I thought we create the macvlan device
directly in the network namespace. There should be no possible
name-conflict with devices on the host...

> 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
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel