Lennart Poettering <lenn...@poettering.net> schrieb: > On Fri, 08.05.15 20:53, Kai Krakow (hurikha...@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. -- Replies to list only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel