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

[Lennart Poettering]

On Mon, 25.05.15 16:26, Kai Krakow (hurikhan77 at gmail.com) wrote:

> Lennart Poettering <lennart at poettering.net> schrieb:
> 
> > On Fri, 08.05.15 20:53, Kai Krakow (hurikhan77 at gmail.com) wrote:
> > 
> >> > # systemd-nspawn -b --link-journal=try-guest --network-macvlan=enp4s0
> >> > # --
> >> > bind=/usr/portage --bind-ro=/usr/src --machine=test
> >> > Spawning container test on /var/lib/machines/test.
> >> > Press ^] three times within 1s to kill container.
> >> > Failed to add new macvlan interfaces: File exists
> >> > 
> >> > I still don't think that systemd-nspawn should insist on creating the
> >> > host- side macvlan bridge and fail, if it cannot. It should just accept
> >> > that it is already there.
> >> 
> >> My findings show that it actually does accept this case. But I had to
> >> explicitly order the machines after network.target to successfully start
> >> at boot time.
> > 
> > I changed git now to order nspawn units by default after
> > network.target now. In the long run we should replace this by calling
> > into networkd though, without waiting for "all" networking, for
> > whatever that means...
> 
> Well, now, with v220, we are back to the original problem:
> 
> machines # systemd-nspawn --boot --link-journal=try-guest --machine=test --
> network-macvlan=enp5s0
> Spawning container test on /var/lib/machines/test.
> Press ^] three times within 1s to kill container.
> Failed to add new macvlan interfaces: File exists
> 
> If mv-enp5s0 is already there (maybe by means of another machine), it no 
> longer starts any other machine on the same macvlan. I don't think this is 
> how it should work.

Well, there can only be one machine with the same name, and we use
that name in the macvlan interface name. Please assign different names
to your containers so that they will also get differently named
macvlan names, and all should be good.

Lennart

-- 
Lennart Poettering, Red Hat